comp.lang.c - 25 new messages in 7 topics - digest
comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en
Today's topics:
* Missing braces around {0} initializer?! - 12 messages, 8 authors
http://groups.google.com/group/comp.lang.c/t/4e761f5803fec708?hl=en
* Motivation of software professionals - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en
* Warning to newbies - 6 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/9597fd702985dff4?hl=en
* newbie question on understanding the main() function - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/47facf1454751d70?hl=en
* compiling C program containing Xutil functions - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/d8c280c034411583?hl=en
* SMTP Client - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/fd5e81482c2e8dd1?hl=en
* Call for Paper The International Journal of Computer Science (IJCS) - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c/t/93f3fe352ba7d9e4?hl=en
==============================================================================
TOPIC: Missing braces around {0} initializer?!
http://groups.google.com/group/comp.lang.c/t/4e761f5803fec708?hl=en
==============================================================================
== 1 of 12 ==
Date: Mon, Feb 8 2010 3:50 pm
From: Tor Rustad
Ben Bacarisse wrote:
> Tor Rustad <bwzcab@wvtqvm.vw> writes:
> <snip>
>> After investigating the gcc man page, I finally (after zillion scrolls):
>>
>> -Wmissing-braces
>> Warn if an aggregate or union initializer is not fully
>> bracketed. In the following example, the initializer for a is not
>> fully bracketed, but that for b is fully
>> bracketed.
>>
>> int a[2][2] = { 0, 1, 2, 3 };
>> int b[2][2] = { { 0, 1 }, { 2, 3 } };
>>
>> This warning is enabled by -Wall.
>>
>>
>>
>> sooo... it appears we need to turn off -Wall, and that's not something
>> I will do.
>
> You need only turn off:
>
> -Wno-missing-braces -Wno-missing-field-initializers
>
> and {0} becomes a silent universal initializer. You will still be
> warned about excess initializers but, sadly, this:
>
> int primes[5] = { 2, 3, 5, 7 };
>
> will be silent too. I can live with that.
>
Ahh.. that did the trick, thanks! I just needed to add
-Wno-missing-braces, and then
gcc -Wall -ansi -pedantic -Wno-missing-braces clc_demo.c
produced no warnings. Using "-Wall -ansi -pedantic" give no warning
anyway for
int primes[5] = { 2, 3, 5, 7 };
so nothing lost in that case.
--
Tor <echo bwzcab@wvtqvm.vw | tr i-za-h a-z>
== 2 of 12 ==
Date: Mon, Feb 8 2010 3:54 pm
From: Phil Carmody
Keith Thompson <kst-u@mib.org> writes:
> Seebs <usenet-nospam@seebs.net> writes:
>> On 2010-02-08, Tor Rustad <bwzcab@wvtqvm.vw> wrote:
>>> I am puzzled by a warning, I get when using {0} as initializer. This
>>> snippet demonstrate the warning:
>>
>>> There was no warning with { {0,0,0} }, but I thought { 0 } was perfectly
>>> conforming C as initializer above. Is this warning a compiler specific
>>> thing which I can turn off somehow, or am I completely missing something
>>> in Standard C here???
>>
>> I believe the answer is neither.
>>
>> Rather, it's a *warning*. A helpful warning that, if you are initializing
>> an array of structures, it is clearer to put braces around the structure
>> initializers. Which it is. Most people won't be quite sure of the semantics
>> of something like
>>
>> struct { int a, b, c; } foo[] = { 1, 2, 3, 4 };
>>
>> and thus gcc warns you that you should probably have the right number of
>> levels of braces.
>>
>> It's not saying your code violates the standard, just that your code has
>> characteristics which are very strongly suggestive that you have made a
>> typo.
>
> Which are very strongly suggestive *to gcc*.
>
> The initializer { 0 } sets all members of the initialized object to
> zero. This is, or should be, a common C idiom. gcc just doesn't
> recognize it.
Please provide proof that it doesn't recognise it. Please be more
detailed than the above - precisely which bit of the construct do
you think it is unable to cope with? From my perspective, it looks
as if it understands the construct and the legality, and typical use,
of same, perfectly.
Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
== 3 of 12 ==
Date: Mon, Feb 8 2010 3:57 pm
From: Phil Carmody
Kaz Kylheku <kkylheku@gmail.com> writes:
> Can you believe the reasoning? Let's break the code /deliberately/ just because
> it invokes undefined behavior
If it's UB, it's already broken, I don't think you can blame
the compiler for shoving that in your face so abruptly. Perhaps
you should thank it, instead?
Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
== 4 of 12 ==
Date: Mon, Feb 8 2010 4:04 pm
From: Tor Rustad
Richard Heathfield wrote:
> Tor Rustad wrote:
>> I am puzzled by a warning, I get when using {0} as initializer.
>
> That warning has irritated me for *years*.
>
> I really wish gcc's warnings were independently configurable.
Like e.g.
-Wno-missing-braces
?
> (Perhaps they are, but that's strictly a matter for a gcc group.)
Yeah, yeah.. nothing has changed here I see. *lol*
--
Tor <echo bwzcab@wvtqvm.vw | tr i-za-h a-z>
== 5 of 12 ==
Date: Mon, Feb 8 2010 4:05 pm
From: Ben Bacarisse
Richard Heathfield <rjh@see.sig.invalid> writes:
> Tor Rustad wrote:
>> I am puzzled by a warning, I get when using {0} as initializer.
>
> That warning has irritated me for *years*.
>
> I really wish gcc's warnings were independently configurable. (Perhaps
> they are, but that's strictly a matter for a gcc group.)
It's the word "strictly" that prompts me to post.
You accept topicality drift within a thread -- into the merits of
Norman Wisdom's slapstick for example -- but you seem to be suggesting
that how one might configure gcc's warnings is beyond the pale.
--
Ben.
== 6 of 12 ==
Date: Mon, Feb 8 2010 4:20 pm
From: Richard
Richard Heathfield <rjh@see.sig.invalid> writes:
> Tor Rustad wrote:
>> I am puzzled by a warning, I get when using {0} as initializer.
>
> That warning has irritated me for *years*.
>
> I really wish gcc's warnings were independently configurable. (Perhaps
> they are, but that's strictly a matter for a gcc group.)
>
> <snip>
Huh? were you not preening about how you personally welcome more
topicality only recently? And I can hardly "C" how discussing one of the
most popular C compilers in the world in a C programming newsgroup is
off topic. Its warnings etc ARE rather linked to the standard ....
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
== 7 of 12 ==
Date: Mon, Feb 8 2010 5:10 pm
From: Keith Thompson
Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Seebs <usenet-nospam@seebs.net> writes:
>>> On 2010-02-08, Tor Rustad <bwzcab@wvtqvm.vw> wrote:
>>>> I am puzzled by a warning, I get when using {0} as initializer. This
>>>> snippet demonstrate the warning:
>>>
>>>> There was no warning with { {0,0,0} }, but I thought { 0 } was perfectly
>>>> conforming C as initializer above. Is this warning a compiler specific
>>>> thing which I can turn off somehow, or am I completely missing something
>>>> in Standard C here???
>>>
>>> I believe the answer is neither.
>>>
>>> Rather, it's a *warning*. A helpful warning that, if you are initializing
>>> an array of structures, it is clearer to put braces around the structure
>>> initializers. Which it is. Most people won't be quite sure of the semantics
>>> of something like
>>>
>>> struct { int a, b, c; } foo[] = { 1, 2, 3, 4 };
>>>
>>> and thus gcc warns you that you should probably have the right number of
>>> levels of braces.
>>>
>>> It's not saying your code violates the standard, just that your code has
>>> characteristics which are very strongly suggestive that you have made a
>>> typo.
>>
>> Which are very strongly suggestive *to gcc*.
>>
>> The initializer { 0 } sets all members of the initialized object to
>> zero. This is, or should be, a common C idiom. gcc just doesn't
>> recognize it.
>
> Please provide proof that it doesn't recognise it. Please be more
> detailed than the above - precisely which bit of the construct do
> you think it is unable to cope with? From my perspective, it looks
> as if it understands the construct and the legality, and typical use,
> of same, perfectly.
Hmm. I really thought I was sufficiently clear.
gcc, like any conforming C compiler, certainly recognizes the
initializer { 0 } and correctly handles its syntax and semantics.
What I meant is that it doesn't recognize it *as an idiom* for
"recursively initialize this object and all its sub-members and
sub-elements to zero".
Consider the following translation unit:
struct s { int x; int y; int z; };
struct s s1 = { 0 };
struct s s2 = { 0, 0 };
With "-Wmissing-field-initializers" or equivalent, gcc warns about
both initializers. With "-Wno-missing-field-initializers", gcc
doesn't warn about either of them.
What I would like is a way to make gcc, or whatever compiler I happen
to be using, to warn about the initialization of s2 (because it's
missing an initializer for z), but not about the initialization
of s1 (because it's using the "{ 0 }" idiom, and I *deliberately*
omitted explicit initializers for most of the members).
One possible drawback is that if I write "{ 0 }", I might really
have meant that the object has exactly one member or element rather
than that I don't want to specify how many it has.
What I'd like even better is a change to the language so that "{ }"
is equivalent to what "{ 0 }" currently means, but I can expect a
compiler not to warn me about it.
I have another idea, but it would break tons of existing code, so it's
unlikely ever to make it into the language. By default, require
explicit initializers for all subobjects. Allow "..." to indicate
that the current subobject and everything following it is implicitly
zero. Thus:
struct s s1 = { 0 }; /* constraint violation */
struct s s2 = { 42, ... }; /* x = 42, y = 0, z = 0 */
struct s s3 = { ... }; /* initialize all members to 0 */
struct s s4 = { 1, 2, 3, ... }; /* probably ok */
There would be a lot of details to work out; since it would break
existing code, I won't bother.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
== 8 of 12 ==
Date: Mon, Feb 8 2010 5:35 pm
From: Andrew Poelstra
On 2010-02-08, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
> Kaz Kylheku <kkylheku@gmail.com> writes:
>> Can you believe the reasoning? Let's break the code /deliberately/ just because
>> it invokes undefined behavior
>
> If it's UB, it's already broken, I don't think you can blame
> the compiler for shoving that in your face so abruptly. Perhaps
> you should thank it, instead?
>
> Phil
I think his point was that it /didn't/ give him an abrupt
warning. It went out of its way to interpret a nonsensical
construct as nonsense rather than issuing a warning.
So it caused a runtime crash.
At least, I think that's what happened. I wasn't quite
clear on his original post either.
== 9 of 12 ==
Date: Mon, Feb 8 2010 6:15 pm
From: William Ahern
Andrew Poelstra <apoelstra@localhost.localdomain> wrote:
<snip>
> Even for
>
> struct test {
> int a;
> int b;
> int c;
> }
>
> int main(void) {
> struct test t = { 0 };
> return 0;
> }
>
> gcc warns me. And it's a particularly irritating warning because
> it individually lists each struct member with a message that I am
> "missing initialization".
>
What version of GCC are you using? I can't replicate that warning with any
of 3.3.5 (OpenBSD), 4.0.1 (Apple), 4.2.1 (Apple), 4.2.4 (Ubuntu), 4.3.3
(GCC), 4.3.4 (Ubuntu), or 4.4.1 (Ubuntu). I've tried -Wall with every
combination of -ansi -pedantic xor -std=c99, and -O2 xor no optimization.
Occasionaly I do get a warning about missing initializers in compound
literals, seemingly without rhyme nor reason. But I never pursued it beyond
checking the code for bugs. Now you've piqued my interest.
Here's the code I used
struct test {
int a, b, c;
};
int main(void) {
struct test t = { 0 };
return t.c;
}
Separately, I tried some combos with `struct test { int a; int b, c; };'.
No difference.
== 10 of 12 ==
Date: Mon, Feb 8 2010 6:46 pm
From: Ben Bacarisse
William Ahern <william@wilbur.25thandClement.com> writes:
> Andrew Poelstra <apoelstra@localhost.localdomain> wrote:
> <snip>
>> Even for
>>
>> struct test {
>> int a;
>> int b;
>> int c;
>> }
>>
>> int main(void) {
>> struct test t = { 0 };
>> return 0;
>> }
>>
>> gcc warns me. And it's a particularly irritating warning because
>> it individually lists each struct member with a message that I am
>> "missing initialization".
>
> What version of GCC are you using? I can't replicate that warning with any
> of 3.3.5 (OpenBSD), 4.0.1 (Apple), 4.2.1 (Apple), 4.2.4 (Ubuntu), 4.3.3
> (GCC), 4.3.4 (Ubuntu), or 4.4.1 (Ubuntu). I've tried -Wall with every
> combination of -ansi -pedantic xor -std=c99, and -O2 xor no
> optimization.
It's turned on with -Wextra.
<snip>
--
Ben.
== 11 of 12 ==
Date: Mon, Feb 8 2010 7:00 pm
From: Seebs
On 2010-02-09, Andrew Poelstra <apoelstra@localhost.localdomain> wrote:
> I think his point was that it /didn't/ give him an abrupt
> warning. It went out of its way to interpret a nonsensical
> construct as nonsense rather than issuing a warning.
I am pretty sure that ALWAYS generates a warning. What it doesn't do
is abort compilation.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
== 12 of 12 ==
Date: Mon, Feb 8 2010 7:34 pm
From: William Ahern
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
<snip>
> It's turned on with -Wextra.
Ah, thank you.
This C99 named initialization construct works w/o any warning:
struct test t = { .a = 0 };
I want to say that the standard explicitly says that every other member is
implicitly zero initialized in this case, but that's just from my poor
memory.
==============================================================================
TOPIC: Motivation of software professionals
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en
==============================================================================
== 1 of 3 ==
Date: Mon, Feb 8 2010 3:50 pm
From: Seebs
On 2010-02-08, Arved Sandstrom <dcest61@hotmail.com> wrote:
> Seebs wrote:
>> On 2010-02-08, Martin Gregorie <martin@address-in-sig.invalid> wrote:
>>> That's easy: anybody who isn't a member of a recognised engineering
>>> society should not be called an engineer and should be laughed out of
>>> town if they call themselves one.
>> This strikes me as the polar opposite of an engineering mindset, which
>> would be that a thing is what it is, and isn't what it isn't, regardless
>> of any labels.
> Insofar as competent and professional engineering societies set real
> standards for qualifications and conduct to be able to use the title
> "Engineer", and insofar as the vast majority of software developers have
> nothing like this at all, I see no problem here.
Membership in an organization is not the same thing as meeting the formal
standards that would be required by such an organization if it existed.
In short, if there exists a set of qualifications and conduct which would
be necessary to be a member of an organization, and membership confers the
title "engineer", then having that set of qualifications and conduct ought
to confer the title *with or without* membership in the organization.
Meanwhile, at least some members of any given organization will usually
not actually meet the nominal or formalized standard in one way or another.
Measurement by proxy is not very good measurement.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
== 2 of 3 ==
Date: Mon, Feb 8 2010 4:01 pm
From: Arved Sandstrom
Seebs wrote:
> On 2010-02-08, Arved Sandstrom <dcest61@hotmail.com> wrote:
>> Seebs wrote:
>>> On 2010-02-08, Martin Gregorie <martin@address-in-sig.invalid> wrote:
>>>> That's easy: anybody who isn't a member of a recognised engineering
>>>> society should not be called an engineer and should be laughed out of
>>>> town if they call themselves one.
>
>>> This strikes me as the polar opposite of an engineering mindset, which
>>> would be that a thing is what it is, and isn't what it isn't, regardless
>>> of any labels.
>
>> Insofar as competent and professional engineering societies set real
>> standards for qualifications and conduct to be able to use the title
>> "Engineer", and insofar as the vast majority of software developers have
>> nothing like this at all, I see no problem here.
>
> Membership in an organization is not the same thing as meeting the formal
> standards that would be required by such an organization if it existed.
>
> In short, if there exists a set of qualifications and conduct which would
> be necessary to be a member of an organization, and membership confers the
> title "engineer", then having that set of qualifications and conduct ought
> to confer the title *with or without* membership in the organization.
> Meanwhile, at least some members of any given organization will usually
> not actually meet the nominal or formalized standard in one way or another.
At the moment those standards do not exist for the majority of software
developers. So it's pretty much a moot point.
If the standards did exist, how would you know that a person who claimed
a title actually deserved it, without having them go through a
certification process?
[ SNIP ]
AHS
== 3 of 3 ==
Date: Mon, Feb 8 2010 6:24 pm
From: Seebs
On 2010-02-09, Arved Sandstrom <dcest61@hotmail.com> wrote:
> At the moment those standards do not exist for the majority of software
> developers. So it's pretty much a moot point.
I am not convinced that they don't; formalization is not existance.
> If the standards did exist, how would you know that a person who claimed
> a title actually deserved it, without having them go through a
> certification process?
How would you know if there WERE a certification process? Answer: You
wouldn't.
It's not as though no one's ever tried it. We have a number of certification
processes. They consistently work, if what you want is to know that someone
once managed to memorize a bunch of stuff for a test. I have seen nothing
to suggest that any other field's "certification processes" are actually
substantially better than this. Certainly, they are extremely popular,
especially among people who have already obtained those certifications.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
==============================================================================
TOPIC: Warning to newbies
http://groups.google.com/group/comp.lang.c/t/9597fd702985dff4?hl=en
==============================================================================
== 1 of 6 ==
Date: Mon, Feb 8 2010 4:08 pm
From: richard@cogsci.ed.ac.uk (Richard Tobin)
In article <3KednY0D1_SDAu3WnZ2dnUVZ8sli4p2d@bt.com>,
Richard Heathfield <rjh@see.sig.invalid> wrote:
>Check out Norman Wisdom. He does it very well indeed.
He's very popular in Albania, apparently.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
== 2 of 6 ==
Date: Mon, Feb 8 2010 4:56 pm
From: Squeamizh
On Feb 8, 12:32 pm, Keith Thompson <ks...@mib.org> wrote:
> Squeamizh <sque...@hotmail.com> writes:
>
> [...]
>
> > I don't know what's more funny- Spinoza's inability to get this simple
> > problem right, or Seebs' continued childish insistence that he only
> > spent five minutes implementing his solution.
>
> What evidence do you have that Seebs spent more than five minutes
> on it?
None, and I didn't mean to imply that I didn't believe him. I just
find it funny.
== 3 of 6 ==
Date: Mon, Feb 8 2010 7:04 pm
From: spinoza1111
The next version of the code followed by its expected output is at the
end of this post. The following changes have been made. Seebs' Swift
Boating looks like it will be fun to demolish when I have
time...perhaps I should just ignore him. It appears to be the same
sort of nonsense he wrote about Schildt, padded with opinions
masquerading as facts.
Seebach is or in 2000 was a fan of George Bush, which makes the
Dijkstra quote apropos.
The following changes have been made:
* New comments have been added to clarify and because comments
constitute an informal proof of correctness.
* The end testing in the scan for replacement strings was not
structured. It has been made so by exploiting C's comma-as-operator
facility and the ability to assign in an expression. I wish I had
these facilities in C sharp.
* The "replace at end" flag in the structure was evilness, since it
was only on in the LAST member of the linked list. It has been removed
and replaced by a test.
* The replace() function now returns a count of replacements.
* An "assertion" has been added to the TESTER macro to verify that
the result string has the predictable length, using the replacement
count.
// ***************************************************************
// * *
// * replace() demo *
// * *
// * Demonstrates how to replace non-NUL-defined strings in C *
// * using a simple function, and bypassing string.h. *
// * *
// * C H A N G E R E C O R D --------------------------------- *
// * DATE PROGRAMMER DESCRIPTION OF CHANGE *
// * -------- ---------- --------------------------------- *
// * 02 07 10 Nilges Version 1.0 *
// * *
// * 02 07 10 Nilges Bug: partial matches not handled *
// * correctly: need to iterate search *
// * for match. *
// * *
// * 02 07 10 Nilges 1. Santosh suggested tests *
// * 2. Heathfield put the boot in re *
// * including malloc *
// * *
// * 02 07 10 Nilges 1. Remove string.h use and code *
// * strlen by hand *
// * 2. Add comment block and comments*
// * inline. *
// * 3. free() storage *
// * 4. Use macro for testing *
// * 5. Bug: calculation of *
// * lngNewLength used incorrect *
// * index (intIndex3 instead of 2)*
// * which caused a memory leak. *
// * *
// * 02 07 10 Nilges 1. Bug: Ike Naar test failed. *
// * At end of scan loop, main *
// * string pointer was not *
// * correctly updated from index3 *
// * *
// * 02 07 10 Nilges Added new Santosh test *
// * *
// * 02 07 10 Nilges Added new Ike Naar test *
// * *
// * 02 08 10 Nilges 1. Added some new comments *
// * 2. Make "check for a complete *
// * match "structured" by means *
// * of a tested assignment *
// * 3. Get rid of "replace at end" *
// * evilness: the only time this *
// * flag is meaningful is in the *
// * LAST segment. *
// * 4. Return replace count *
// * 5. TESTER macro assertion added *
// * *
// * ----------------------------------------------------------- *
// * *
// * "In the near future we shall have to live with the *
// * superstition that programming is 'so easy that even a *
// * Republican can do it!'" *
// * *
// * - E. W. Dijkstra *
// * *
// * *
// ***************************************************************
#include <stdio.h>
#include <stdlib.h>
// ***** Segmentation *****
struct TYPsegmentstruct
{ char * strSegment;
long lngSegmentLength;
struct TYPsegmentstruct * ptrNext; };
// ---------------------------------------------------------------
// Calculate string length
//
//
long strLength(char *strInstring)
{
char *ptrInstring;
for (ptrInstring = strInstring; *ptrInstring; ptrInstring++);
return ptrInstring - strInstring;
}
// ---------------------------------------------------------------
// Replace target by replacement string in master string
//
//
// Caution: the string returned by this function should be freed.
//
//
char * replace(char * strMaster,
char * strTarget,
char * strReplacement,
long * ptrReplacements)
{
char * ptrIndex0;
char * ptrIndex1;
char * ptrIndex2;
char * ptrIndex3;
char * strNew;
char * strNewStart;
long lngNewLength;
long lngCount;
long lngReplacementLength;
struct TYPsegmentstruct * ptrSegmentStructStarts;
struct TYPsegmentstruct * ptrSegmentStruct;
struct TYPsegmentstruct * ptrSegmentStructPrev;
lngReplacementLength = strLength(strReplacement);
if (!*strTarget)
{
printf("Error in calling replace(): target can't be null");
abort();
}
ptrIndex1 = strMaster;
ptrSegmentStructPrev = 0;
lngNewLength = 0;
*ptrReplacements = 0;
while(*ptrIndex1)
{
ptrIndex0 = ptrIndex1;
while (-1)
{
// --- Check for (one character) handle
for(;
*ptrIndex1 && *ptrIndex1 != *strTarget;
ptrIndex1++);
// --- Check for complete match
for(ptrIndex2 = strTarget, ptrIndex3 = ptrIndex1;
*ptrIndex3
&&
*ptrIndex2
&&
*ptrIndex3 == *ptrIndex2;
ptrIndex3++, ptrIndex2++);
// End test: check complete match, update main ptr past
// partial match while checking for end of loop
if ((!*ptrIndex2 ? ((*ptrReplacements)++, -1) : 0)
||
!*(ptrIndex1 = ptrIndex3)) break;
}
// --- Create new segment
if (!(ptrSegmentStruct =
malloc(sizeof(struct TYPsegmentstruct))))
abort();
ptrSegmentStruct->strSegment = ptrIndex0;
ptrSegmentStruct->lngSegmentLength =
ptrIndex1 - ptrIndex0;
ptrSegmentStruct->ptrNext = 0;
if (ptrSegmentStructPrev != 0)
ptrSegmentStructPrev->ptrNext = ptrSegmentStruct;
else
ptrSegmentStructStarts = ptrSegmentStruct;
ptrSegmentStructPrev = ptrSegmentStruct;
// --- Update mallocation length
lngNewLength += ptrSegmentStruct->lngSegmentLength +
(!*ptrIndex2
?
lngReplacementLength
:
0);
// --- Get past end of target string & iterate
ptrIndex1 = ptrIndex3;
}
// --- Allocate just enough storage for the new string
if (!(strNewStart = malloc(lngNewLength + 1))) abort();
// --- Build the new string whilst freeing the list
strNew = strNewStart;
ptrSegmentStruct = ptrSegmentStructStarts;
while (ptrSegmentStruct)
{
for (ptrIndex1 = ptrSegmentStruct->strSegment,
lngCount = 0;
lngCount < ptrSegmentStruct->lngSegmentLength;
ptrIndex1++, lngCount++, strNew++)
*strNew = *ptrIndex1;
if (ptrSegmentStruct->ptrNext || !*ptrIndex2)
for (ptrIndex1 = strReplacement;
*ptrIndex1;
ptrIndex1++, ++strNew)
*strNew = *ptrIndex1;
ptrSegmentStructPrev = ptrSegmentStruct;
ptrSegmentStruct = ptrSegmentStruct->ptrNext;
free(ptrSegmentStructPrev);
}
*strNew = '\0';
return strNewStart;
}
// ---------------------------------------------------------------
// Statement-format test macro
//
//
#define TESTER(resultPtr, master, target, replacement, expected,
expectedReplacements, replacements) \
{ \
printf("Replace \"%s\" by \"%s\" in \"%s\"\n", \
(target), (replacement), (master)); \
printf("Expect \"%s\":\n\"%s\"\n", \
(expected), \
resultPtr = replace((master), \
(target), \
(replacement), \
&(replacements))); \
printf("Replacements expected: %d: replacements: %d\n", \
(expectedReplacements), \
(replacements)); \
if (!(strLength(resultPtr) \
== \
strLength(master) \
+ \
(strLength(replacement)-strLength(target)) \
* \
replacements)) \
printf("Assertion failed\n"); \
printf("\n\n"); \
free(resultPtr); \
}
// ---------------------------------------------------------------
// Main procedure
//
//
int main()
{
char *ptrResult;
long lngReplacements;
printf("\nReplace\n\n\n");
TESTER(ptrResult,
"a stupid error",
"stupid error",
"miracle",
"a miracle",
1,
lngReplacements)
TESTER(ptrResult,
"a stupid error",
"stupid",
"miracle",
"a miracle error",
1,
lngReplacements)
TESTER(ptrResult,
"the stupid error",
"the stupid error",
"a miracle",
"a miracle",
1,
lngReplacements)
TESTER(ptrResult,
"the miracle",
"the",
"a",
"a miracle",
1,
lngReplacements)
TESTER(ptrResult,
"a miraclsnirpKamunkle",
"snirpKamunkle",
"e",
"a miracle",
1,
lngReplacements)
TESTER(ptrResult,
"a miraclesnirpKamunkle",
"a miracle",
"",
"snirpKamunkle",
1,
lngReplacements)
TESTER(ptrResult,
" a miraclesnirpKamunkle",
"a miracle",
"",
" snirpKamunkle",
1,
lngReplacements)
TESTER(ptrResult,
" a miraclesnirpKamunklea miraclea miracle",
"a miracle",
"",
" snirpKamunkle",
3,
lngReplacements)
TESTER(ptrResult,
"a miracle a miraclesnirpKamunkle a Miraclea miraclea
miracle",
"a miracle",
"",
" snirpKamunkle a Miracle",
4,
lngReplacements)
TESTER(ptrResult,
"a stupid errord",
"stupid error",
"miracle",
"a miracled",
1,
lngReplacements)
TESTER(ptrResult,
"a stupid errod",
"stupid error",
"miracle",
"a stupid errod",
0,
lngReplacements)
TESTER(ptrResult,
"a sstupid error",
"stupid error",
"miracle",
"a smiracle",
1,
lngReplacements)
TESTER(ptrResult,
"a stupid errorstupid error",
"stupid error",
"miracle",
"a miraclemiracle",
2,
lngReplacements)
TESTER(ptrResult,
"a stupid error stupiderror",
"stupid error",
"miracle",
"a miracle stupiderror",
1,
lngReplacements)
TESTER(ptrResult,
"bbbbbbbbbb",
"b",
"a",
"aaaaaaaaaa",
10,
lngReplacements)
TESTER(ptrResult,
"In the halls of R'yleh great %s lies dreaming",
"%s",
"Cthulu",
"In the halls of R'yleh great Cthulu lies dreaming",
1,
lngReplacements)
TESTER(ptrResult,
"%s%s%s%s%s%s",
"%s",
"Cthulu",
"CthuluCthuluCthuluCthuluCthuluCthulu",
6,
lngReplacements)
TESTER(ptrResult,
"banana",
"ana",
"oat",
"boatna",
1,
lngReplacements)
TESTER(ptrResult,
" a stupid errorstupid errorHeystupid errors",
"stupid error",
"+",
" a ++Hey+s",
3,
lngReplacements)
TESTER(ptrResult,
"foo barfoo barf",
"foo bar",
"bas",
"basbasf",
2,
lngReplacements)
TESTER(ptrResult,
"abab",
"ba",
"ba",
"abab",
1,
lngReplacements)
TESTER(ptrResult,
"abab",
"bab",
"boop",
"aboop",
1,
lngReplacements)
printf("\n\nTesting complete: check output carefully: \"Assertion
failed\" should not occur!\n\n");
return 0;
}
Replace
Replace "stupid error" by "miracle" in "a stupid error"
Expect "a miracle":
"a miracle"
Replacements expected: 1: replacements: 1
Replace "stupid" by "miracle" in "a stupid error"
Expect "a miracle error":
"a miracle error"
Replacements expected: 1: replacements: 1
Replace "the stupid error" by "a miracle" in "the stupid error"
Expect "a miracle":
"a miracle"
Replacements expected: 1: replacements: 1
Replace "the" by "a" in "the miracle"
Expect "a miracle":
"a miracle"
Replacements expected: 1: replacements: 1
Replace "snirpKamunkle" by "e" in "a miraclsnirpKamunkle"
Expect "a miracle":
"a miracle"
Replacements expected: 1: replacements: 1
Replace "a miracle" by "" in "a miraclesnirpKamunkle"
Expect "snirpKamunkle":
"snirpKamunkle"
Replacements expected: 1: replacements: 1
Replace "a miracle" by "" in " a miraclesnirpKamunkle"
Expect " snirpKamunkle":
" snirpKamunkle"
Replacements expected: 1: replacements: 1
Replace "a miracle" by "" in " a miraclesnirpKamunklea miraclea
miracle"
Expect " snirpKamunkle":
" snirpKamunkle"
Replacements expected: 3: replacements: 3
Replace "a miracle" by "" in "a miracle a miraclesnirpKamunkle a
Miraclea miraclea miracle"
Expect " snirpKamunkle a Miracle":
" snirpKamunkle a Miracle"
Replacements expected: 4: replacements: 4
Replace "stupid error" by "miracle" in "a stupid errord"
Expect "a miracled":
"a miracled"
Replacements expected: 1: replacements: 1
Replace "stupid error" by "miracle" in "a stupid errod"
Expect "a stupid errod":
"a stupid errod"
Replacements expected: 0: replacements: 0
Replace "stupid error" by "miracle" in "a sstupid error"
Expect "a smiracle":
"a smiracle"
Replacements expected: 1: replacements: 1
Replace "stupid error" by "miracle" in "a stupid errorstupid error"
Expect "a miraclemiracle":
"a miraclemiracle"
Replacements expected: 2: replacements: 2
Replace "stupid error" by "miracle" in "a stupid error stupiderror"
Expect "a miracle stupiderror":
"a miracle stupiderror"
Replacements expected: 1: replacements: 1
Replace "b" by "a" in "bbbbbbbbbb"
Expect "aaaaaaaaaa":
"aaaaaaaaaa"
Replacements expected: 10: replacements: 10
Replace "%s" by "Cthulu" in "In the halls of R'yleh great %s lies
dreaming"
Expect "In the halls of R'yleh great Cthulu lies dreaming":
"In the halls of R'yleh great Cthulu lies dreaming"
Replacements expected: 1: replacements: 1
Replace "%s" by "Cthulu" in "%s%s%s%s%s%s"
Expect "CthuluCthuluCthuluCthuluCthuluCthulu":
"CthuluCthuluCthuluCthuluCthuluCthulu"
Replacements expected: 6: replacements: 6
Replace "ana" by "oat" in "banana"
Expect "boatna":
"boatna"
Replacements expected: 1: replacements: 1
Replace "stupid error" by "+" in " a stupid errorstupid errorHeystupid
errors"
Expect " a ++Hey+s":
" a ++Hey+s"
Replacements expected: 3: replacements: 3
Replace "foo bar" by "bas" in "foo barfoo barf"
Expect "basbasf":
"basbasf"
Replacements expected: 2: replacements: 2
Replace "ba" by "ba" in "abab"
Expect "abab":
"abab"
Replacements expected: 1: replacements: 1
Replace "bab" by "boop" in "abab"
Expect "aboop":
"aboop"
Replacements expected: 1: replacements: 1
Testing complete: check output carefully: "Assertion failed" should
not occur!
== 4 of 6 ==
Date: Mon, Feb 8 2010 7:14 pm
From: spinoza1111
On Feb 8, 1:08 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-08, Joe Wright <joewwri...@comcast.net> wrote:
>
> > I must be missing something.spinoza1111came up with almost 100 lines of
> > code to solve what I consider to be a simple problem solvable in 10 lines
> > or so.
>
> A classic example of massively overthinking a problem.
Overthinking? Wow. When I started out, IBM programmers had signs
saying Think, and they produced real wealth (which was massively
stolen by the microkids). They also had long-term economic security.
After the election of Reagan, they were replaced by ADHD and substance-
abusing creeps because the game (as in the former Soviet Union) became
smashing and grabbing wealth created by the labor and taxes of the
middle class in the USA, and the labor of the proletariat in the
Soviet Union.
The result? A few slobs became rich and for the middle class, the game
changed to the display of subservience to existing "solutions" at all
time, coupled with the deliberate projection of lack of craft
(masquerading as "real" craft) and the abuse of the poor and homeless.
The result? A best-selling computer book: "Don't Make Me Think".
>
> One of the most useful skills in programming is learning when you don't need
> to build an entire infrastructure layer to support a straightforward
> operation.
But I haven't "built an entire infrastructure layer", dear little man.
The strstr scan is embedded in the code without being separated.
>
> I just hope he never realizes that his implementation of a string length
> counter is not particularly overth^H^H^H^H^Hrobustly engineered. If he does,
> we'll get something like this:
>
> #include <sys\types.h>
> #include "curses.h"
> #include <iso646.H>
> #include <emmintrin.h>
>
> /* C does not provide a value which is distinct from all possible
> * char values, because the idiots who wrote the standard didn't
> * realize that the "char" type which they stupidly left undefined
> * could hold the value -1.
> */
> #define EndOfFileValue -3
>
> int isPointerNull(void *p) {
> if ((void *) p == (void *) 0) {
> return ~0;
> } else {
> return 0;
> }
> /* because the standard was written by autistic twerps who have
> * never studied computer science, it is crucially important that
> * there be an explicit return statement at the end of every
> * function.
> */
> return 0;
> }
>
> int characterAtPointer(const char *pointerToCharacter) {
> if (isPointerNull((void *)pointerToCharacter) == ~0) {
> return EndOfFileValue;
> } else {
> return pointerToCharacter[(int) 0];
> }
> return EndOfFileValue;
> }
>
> int lengthOfString(const char *stringToMeasure) {
> int nextCharacter;
> int nextCharacterIsEndOfFileValue;
> const char *nextCharacterPointer;
> int charactersSoFar;
> if (isPointerNull((void *)stringToMeasure)) {
> return ~0;
> } else {
> /* important not to modify the caller's string, which is on
> * the STACK STACK STACK STACK STACK STACK STACK STACK you
> * transvestite nazi motherfuckers
> */
> nextCharacterPointer = stringToMeasure;
> charactersSoFar = 0;
> nextCharacterIsEndOfFileValue = 0;
> /* the following monstrosity is necessary because C is
> * intrinsically unsafe, providing no type-safe way to
> * extract a value from a pointer without first verifying
> * that the pointer is valid, as I proved in the 1980s.
> */
> while(characterAtPointer((const char *)nextCharacterPointer) != '\0' && nextCharacterIsEndOfFileValue != ~0) {
> if (characterAtPointer((const char *)nextCharacterPointer) == EndOfFileValue) {
> nextCharacterIsEndOfFileValue = ~0;
> }
> if (nextCharacterIsEndOfFileValue != ~0) {
> nextCharacter = characterAtPointer((const char *)nextCharacterPointer);
> if (nextCharacter == '\0') {
> /* when I was working with Ogden Nash,
> * he told me to always phrase my tests in
> * a positive way
> */
> } else {
> charactersSoFar = charactersSoFar + (int) 1;
> }
> }
> nextCharacterPointer = (const char *) &nextCharacterPointer[1];
> }
> }
> return (int) charactersSoFar;
> }
>
> -s
> p.s.: Needless to say, I have not tried to compile the above fragment.
> However, I consider it fairly representative.
> --
> Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
You've written this code and presented it as mine. This is egregious
dishonesty and highly unprofessional. In my experience, incompetent
programmers turn to lies and mockery when their incompetence is
exposed.
== 5 of 6 ==
Date: Mon, Feb 8 2010 7:21 pm
From: spinoza1111
On Feb 9, 4:32 am, Keith Thompson <ks...@mib.org> wrote:
> Squeamizh <sque...@hotmail.com> writes:
>
> [...]
>
> > I don't know what's more funny- Spinoza's inability to get this simple
> > problem right, or Seebs' continued childish insistence that he only
As I said, I posted the code for COLLABORATIVE development and
testing, and I received professional assistance from Santosh and Ike
Naar, which helped me to complete the project.
That is what this ng was meant for: not for posting "satiric" code as
mine in an actionably libelous lie.
Santosh and Ike Naar found problems which I fixed in a few hours on
Sunday.
Heathfield and Seebie have demonstrated that they are disruptive
creeps.
Don't you DARE compare me to them! There is NO comparision. They are
subprofessional clerks and temps who are misusing this newsgroup to
pretend they are professionals.
> > spent five minutes implementing his solution.
>
> What evidence do you have that Seebs spent more than five minutes
> on it?
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
> Nokia
> "We must do something. This is something. Therefore, we must do this."
> -- Antony Jay and Jonathan Lynn, "Yes Minister"
== 6 of 6 ==
Date: Mon, Feb 8 2010 9:43 pm
From: spinoza1111
On Feb 9, 11:21 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Feb 9, 4:32 am, Keith Thompson <ks...@mib.org> wrote:
Keith: there is absolutely no comparision between myself and other
noble and fine spirits here such as Kenny and Navia, and creeps like
Seebach.
There is a certain sort of Creep
Who creeps, along the Way
As the shadows gather
At the end of day.
His Traffic is in lies
Rumor, and surmise
His purpose, to give Pain
The light, he does disdain.
Hellish hurt he tries to give
But he does not Succeed
The Knight who has a mission
To daemon pays no heed.
==============================================================================
TOPIC: newbie question on understanding the main() function
http://groups.google.com/group/comp.lang.c/t/47facf1454751d70?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Feb 8 2010 5:19 pm
From: some
Thanks to all who responded.
Philip Potter wrote:
> On 08/02/2010 03:46, some wrote:
> > Thanks to all who responded to my question.
> >
> > Richard Heathfield wrote:
> >> some wrote:
> >>> If i write main like the following ways. Which one will compile and
> >>> why?
> >>>
> >>> 1. char * main();
> >>> 2. char * main(int, char);
> >>> 3. char * main(char);
> >>>
> >>> I guess only first will(but, all three will flag a warning from the
> >>> compiler)
> >>
> >> They are all wrong, but the compiler is not required to diagnose any of
> >> them. This is one of those cases where the compiler is allowed to expect
> >> you to know what you're doing;
> >
> > How do I know which cases are such(where compiler will not flag an
> > error, but actually
> > legal so don't evoke an error message from compiler)? I realize cases
> > where I am
> > allocating/deallocating memory, doing pointer arithmetic, returning
> > address of a local
> > variable from a function are cases where compiler will not balk as
> > they are legal, but are
> > wrong?
> >
> > Which book should I read to know about such cases?
>
> A good starting place would be to read through the comp.lang.c FAQ at
> http://c-faq.com/. There's a lot of discussion of different types of
> not-well-defined-but-not-necessarily-error-producing code there to get
> you started; particularly the sections on expressions, pointers and
> memory allocation, but elsewhere too.
>
> However, while it is a good resource, it is not enough on its own; it
> must be read *in addition* to a good textbook such as those recommended
> by santosh.
>
> Also, if you haven't done so already, you should find out how to turn on
> your compiler's stricter error checking modes. You mentioned you were
> using gcc, so try:
>
> gcc -ansi -pedantic -Wall -Wextra -o<destination> <source>
>
> -ansi turns off extensions which are not allowed by the Standard
> -pedantic emits all diagnostics (warnings) required by the Standard
> -Wall turns on lots more warnings
> -Wextra turns on even more warnings [can use -W instead of -Wextra]
>
> In this case, -Wall enables the -Wmain warning:
> -Wmain
> Warn if the type of main is suspicious. main should be a function
> with external linkage, returning int, taking either zero arguments,
> two, or three arguments of appropriate types. This warning is
> enabled by -Wall.
I will turn on the warnings as you suggest and use lint if it
is available on my system to catch such mistakes which are legal
but lead to undefined behavior.
I will also go through the Standard, K&R
and Harrison Steele's Reference manual. The Harrison Steele's C
Reference manual
book looks more difficult to understand than the K&R
and the examples at the end of each chapter are certainly tougher for
me than K&R.
Perhaps, I am too dense as I hear high school students and college
freshmen solve them easily
I need some sharpening of wits.
Thanks again to all who responded.
==============================================================================
TOPIC: compiling C program containing Xutil functions
http://groups.google.com/group/comp.lang.c/t/d8c280c034411583?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Feb 8 2010 5:36 pm
From: Ian Collins
happytoday wrote:
>
> The problem that I did know well what files concerning these functions
> so I compiled with the below errors
How did you resolve them in 2006?
--
Ian Collins
==============================================================================
TOPIC: SMTP Client
http://groups.google.com/group/comp.lang.c/t/fd5e81482c2e8dd1?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Feb 8 2010 6:07 pm
From: J
I am starting a new project to create a SMTP Client for Windows; I am
using the winsock2 library. When I use the following commands I get an
error (550):
220 ns1.zanmo.com ESMTP Exim 4.69 Mon, 08 Feb 2010 17:58:41 -0800
HELO world
250 ns1.zanmo.com Hello 60.sub-75-229-11.myvzw.com [75.229.11.60]
MAIL FROM: test@test.com
250 OK
RCPT TO: test@gmail.com
550 authentication required
QUIT
221 ns1.zanmo.com closing connection
Please explain how to authenticate the session, and how do I
Programmatically MX Lookup also using MX record?
==============================================================================
TOPIC: Call for Paper The International Journal of Computer Science (IJCS)
http://groups.google.com/group/comp.lang.c/t/93f3fe352ba7d9e4?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Feb 8 2010 9:35 pm
From: editor ijcs
Call for Paper
The International Journal of Computer Science (IJCS) publishes
original papers on all subjects relevant to computer science,
communication network, and information systems. The highest priority
will be given to those contributions concerned with a discussion of
the background of a practical problem, the establishment of an
appropriate model, the determination of a solution, approximate or
exact, analytical or numerical, and a discussion of the relevance of
the results when applied to the real-life problem. Paper submissions
are invited in the area of computer science, in particular the
technological advances and research results in the fields of
theoretical, experimental, applied electronics, computer science,
communication network and Information technology.
Topics of interest include but are not limited to the following:
Computer Science
* Parallel Processing and Distributed Computing
* Foundations of High-performance Computing
* Graph Theory and Analysis of Algorithms
* Artificial Intelligences and Pattern/Image Recognitions
* Neural Networks and Biomedical Simulations
* Virtual Visions and Virtual Simulations
* Data Mining, Web Image Mining and Applications
* Data Base Management & Information Retrievals Adaptive Systems
* Bifurcation, Biocybernetics & Bioinformatics
* Blind Systems, Neural Networks &Control Systems
* Cryptosystems &Data Compression
* Evolutional Computation &Fuzzy Systems
* Image Processing and Image Recognition, Modeling & Optimization
* Speech Processing, Speech Synthesis & Speech Recognition
* Video Signal Processing, Watermarking & Wavelet Transform
* All topics related Computer Science
Communication Network
* Quantum Computing & Coding
* Error Controls Agent Computing & Multi-Agents Systems
* Defining Spectrum Rights and Open Spectrum Solutions
* Quality of Services and Communication Protocols
* Satellite and Optical Communication Systems
* 3G/4G Network Evolutions & CDMA/GSM Communication Protocols
* Mobile Computing, Transmission/Switching/Distribution
technologies
* Communication Theory & Signal Processing for Communications
* Wireless Communications, Wireless & Mobile Networking
* Optical Networks and Systems &Next-Generation Networking and
Internet
* Communication QoS &Reliability and Modeling
* Ad-hoc, Sensor & Mesh Networking
* Multimedia Services, Communication Software & Services
* Communication and Information System Security
* System control and network/service management
* Network and Internet protocols and standards
* Client-server, distributed & Web-based communication systems
* Broadband and multimedia systems & applications
* Trials of advanced systems and services
* Any topics related Communication Network
Information and Systems
* Cryptography and Foundation of Computer Security
* Authentication/Authorization Issues
* IDS/Firewall, Anti-Spam mail & Anti-virus issues
* Biometric authentication & algorithms
* Fingerprint /Hand/Biometrics Recognitions and Technologies
* IC-card Security, OTP & Key Management Issues
* E-commerce, Ubiquitous & RFID Applications
* Metadata, Meta Modeling, XML & Data Management
* Knowledge Management, Web Security & Privacy
* Cyber Threats, Web Services & Web Engineering
* Web Intelligence, Protocols & Standards
* Proxies and Servers
* Multimedia Applications
* Ontology and the Semantic Web
* B2B, B2C and C2C
* E-Business System Design and Development, E-Payment
* Portal Strategies, Social Networks and Information Systems
* Social and Legal Issues and Digital Ecology
* E-Governance, E-Learning and Virtual Classrooms
* E-Entertainment, E-Journalism
* Any topics related Information systems
Electronics
* Circuits & Devices
* Communication Networks & Systems
* Communications & Information Processing
* Digital Signal Processing & Electrical Engineering
Communications
* Electromagnetics & Microwaves
* Instrumentation
* Measurement & Testing
* Nanoscience & Nanotechnology
* Optics & Optoelectronic Effects
* Devices, Systems &Semiconductors
* Systems & Control Engineering
* Telecommunications
* Any topics related Electronics
International Journal of Computer Science (IJCS)
ISSN: 1884-9083
Website: https://sites.google.com/site/ijcsorg/
Manuscript submission to: ijcsorgeditor@gmail.com
All submitted papers will be judged based on their quality by the
technical committee and reviewers. Papers that describe research and
experimentation are encouraged. All paper submissions will be handled
electronically and detailed instructions on submission procedure are
available on IJCS web pages. Researchers and authors are invited to
participate in the peer-review process of IJCS papers if your research
interest matches with the themes of Call for Papers. For other
information, please contact IJCS Managing Editor.
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en
To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home