So what Standard are we working off?

[santosh]

lovecreatesbeauty said:

.... snip ...

Why not just assume that 0 is false and non-zero is true?

As an aside, is there an explanation why certain function in the
standard library return 0 to indicate success while certain others
return 1 for the same? Is it a historical/legacy issue or is there a
method behind the apparent inconsistency?

I use 1 to indicate success and 0 for failure in all my private
functions, since that's the convention adopted in electronics.

 

[Mark F. Haigh]

Frederick Gotham said:


I think the part of the C community that cares about portability wants a
widely-implemented standard, which it already has. Until C99 becomes as
widespread as C90, why would anyone use it if they need portability?

Come on, quit being so negative. Having everybody agree on "restrict"
now, for example, is better than a bunch of subtly incompatible type
aliasing optimization extensions later.

And the part of the C community that couldn't give two hoots about
portability aren't interested in the Standard anyway - they just want
something that works on /their/ compiler, and many such people think the
Standard (if they've even heard of it) takes second place to their compiler
documentation.

C99-isms are creeping in, slowly. "restrict" works on Intel C, GCC,
the Sun C, and the HPUX C, and IBM VisualAge for AIX. The stdint.h
typedefs are working their way into just about everywhere. No need for
despair.

The presumption that people are using it, which is a far from accurate
presumption. I am not using C99, and as far as my compiler is concerned the
// comment is a syntax error, and I wish people wouldn't use it in clc
because it means an extra step for me before I can compile the code.

<snip>

I use C99 features where I can. Most have hackish or platform-specific
fallbacks that work well enough. As an example, it's nice to use the
struct hack as a fallback-only thing.

Mark F. Haigh
(e-mail address removed)

 

[Richard Bos]

As an aside, is there an explanation why certain function in the
standard library return 0 to indicate success while certain others
return 1 for the same? Is it a historical/legacy issue or is there a
method behind the apparent inconsistency?

Most of it is on the one hand a varying value (say, a character count)
for success, 0 for failure; and on the other hand a boolean 0 for found
no exception, 1 for found an exception. I haven't checked all of the
library to see whether this is kept to consistently, but it does cover
the majority, I think.

Richard

 

[Keith Thompson]

typedef int32 bool_t;
#define true 1
#define false 0

This works fine, why bother to add three keywords and modify the
language.

Because <EXAGGERATE>everybody</EXAGGERATE> does the same thing, but
slightly differently. With a consistent set of declarations in the
standard, we can avoid inconsistencies and conflicts.

Try compiling a program that uses two libraries, both of which define
"true", "false", and "bool", but with incompatible definitions of
"bool".

(BTW, why int32 rather than int?)

The language (with the revised standard) manages it and guarantees the
memory allocation for VLAs, normal arrays, ints and doubles. It is
promising it, right?

What promise are you talking about?

Do you worry if this fails: Char arr[999999];

I wouldn't put a declaration like that inside a function. But this:

char arr[n];

can work just fine until somebody calls the function with n = 999999.

 

[Richard Heathfield]

santosh said:

... snip ...


As an aside, is there an explanation why certain function in the
standard library return 0 to indicate success while certain others
return 1 for the same?

Off-hand, I can't think of any C standard library functions that return 0 to
mean "success", but no doubt you have an example in mind. Having said that,
I generally use 0 for that purpose, which leaves all the other possible int
values for documenting the exact error that occurred. When I make an
exception, it is for pointer-returning functions, where clearly NULL is the
only value I can reasonably choose to mean "oopsie" (e.g. "couldn't
allocate this resource").

Is it a historical/legacy issue or is there a
method behind the apparent inconsistency?

Actually, the consistency is pretty good! But different kinds of function
have different purposes, so the consistency is within function groups,
rather than across the board. This is not unreasonable.

Functions that determine a truth/falsehood - is* - return 0 for false and
non-zero for true.

Functions that determine a relationship - *cmp, and our own int(*)(const
void *, const void *) - return < 0 for less, 0 for equal, and > 0 for
greater.

Functions that yield a count - fread, fwrite, strlen, strspn, strcspn -
return 0 for a 0 count, > 0 for a non-zero count.

Functions that yield a pointer - fgets, malloc, strstr, strtok - return a
valid pointer if they can, or NULL if they can't.

Functions that yield the result of a calculation - sin, cos, tan, strtol,
strtod - tend to report errors via some other mechanism than their return
value (e.g. domain errors, endptr, whatever).

Functions that retrieve or process a single character - getc, fgetc,
getchar, to* - yield EOF on error.

I do not claim that the consistency within groups is 100%, but off the top
of my head I can't think of any counter-examples within the categories I've
listed.

 

[Richard Heathfield]

Mark F. Haigh said:

Richard Heathfield wrote:


Come on, quit being so negative. Having everybody agree on "restrict"
now, for example, is better than a bunch of subtly incompatible type
aliasing optimization extensions later.

Not if it stops my program from compiling.

<snip>

 

[pete]

... snip ...

Nothing could be simpler!

As an aside, is there an explanation why certain function in the
standard library return 0 to indicate success while certain others
return 1 for the same? Is it a historical/legacy issue or is there a
method behind the apparent inconsistency?

I use 1 to indicate success and 0 for failure in all my private
functions, since that's the convention adopted in electronics.

I think main is the only function in the standard,
(not to be confused with the standard library)
that returns 0 for success.
Returning 0 for success enables various modes of failure
to be indicated by various non zero return values,
none of which are mentioned in the standard,
but which would have to be implementation defined.

 

[Guest]

Mark F. Haigh said:


Not if it stops my program from compiling.

It shouldn't if you define restrict as an empty macro in C90 mode, or
otherwise hide it.

 

[Richard Heathfield]

Harald van D?k said:

It shouldn't if you define restrict as an empty macro in C90 mode, or
otherwise hide it.

I have found that the best way to hide restrict is not to define it at all,
not to use it, not to even think about using it, except of course as a
perfectly normal identifier. As far as I'm concerned, it's in user
namespace, and the C standardeers have no business polluting that space.

 

[Guest]

Harald van D?k said:


I have found that the best way to hide restrict is not to define it at all,
not to use it, not to even think about using it, except of course as a
perfectly normal identifier. As far as I'm concerned, it's in user
namespace, and the C standardeers have no business polluting that space.

Sorry, I think I misunderstood your previous message. I thought you
meant a C99 program using "restrict" would not compile with a C90
compiler, but you probably meant a C90 program using an identifier
"restrict" would not compile with a C99 compiler, right? If so, I think
it's annoying if you actually have such code, but pretty much
unavoidable unless you want to use something like __restrict instead. I
haven't seen restrict myself as an identifier, but I have seen inline()
functions which cause the same problems.

 

[Roberto Waltman]

Mine also.

typedef int32 bool_t;
#define true 1
#define false 0

This works fine, why bother to add three keywords and modify the
language.

Because not everybody will do exactly that. I have seen all of the
following:

typedef <some_int_type> bool;
typedef <some_int_type> bool_t;
typedef <some_int_type> Bool;
typedef <some_int_type> Bool_t;
typedef <some_int_type> BOOL;
typedef <some_int_type> boolean;
/* for Fortranistas: */
typedef <some_int_type> logical;
/* and Logical, and LOGICAL ... */

And so on. Use any possible variation of <some_int_type>, and then
duplicate the list using #define instead of typedef.
Then continue with:

#define true 1
#define true (~false)
#define True 1
#define TRUE 1
#define T 1
#define true (-1)
#define True (-1)
#define TRUE (-1)
#define T (-1)

enum { TRUE = ... }

Tautology of the day: If it is not standardized unless it is in the
standard.

 

[Frederick Gotham]

lovecreatesbeauty posted:

typedef int32 bool_t;
#define true 1
#define false 0

That's flawed, and I'll show you why:

int Func1() { return 5; }

int Func2() { return 1; }

int main(void)
{
bool_t result1 = Func1();

bool_t result2 = Func2();

if ( result1 == result2 ) DoSomething();
}


(The preceeding snippet would work as expected in C++ with the built-in
"bool" type.)

 

[Tom St Denis]

int main(void)
{
bool_t result1 = Func1();

bool_t result2 = Func2();

if ( result1 == result2 ) DoSomething();
}

(The preceeding snippet would work as expected in C++ with the built-in
"bool" type.)

You shouldn't use == for bool types though. It's a logical type not
arithmetic type [a distinction solely made in the intent of the program
and not the C language].

if (result1 && result2) DoSomething();

Would work fine in C too.

Tom

 

[Roberto Waltman]

...
Tautology of the day: If it is not standardized unless it is in the
standard.

Argh! Not enough coffee. Tautology of the day: It is not standardized
unless it is in the standard.

 

[lovecreatesbeauty]

lovecreatesbeauty said:

Keith Thompson wrote:

The language (with the revised standard) manages it and guarantees the
memory allocation for VLAs, normal arrays, ints and doubles.

Up to a point.

It is promising it, right?

No, it promises you can definitely have /one/ object 65535 bytes in size.

Do you worry if this fails: Char arr[999999];

It doesn't even compile. And if it did, it isn't guaranteed to succeed.

A whole C source file in a well format and without typo can't
certainly be supposed as quality code. Do you agree?

What I meant was even a single int i; or int arr[1] like those in the
following small snippet has a chance to fail. (Perhaps this example can
not demonstrate the dangerous. People with wisdom like you, Mr.
Heathfield may do it, don't you?). You pay attention to VLA, you also
pay attention to int i, it's great.

int main(void)
{
for (;
{
int i;
int arr[1];
/*do calculations on the above objects*/
}
}

No,
I don't worry if it fails because I Am Not Stupid Enough To Do It Like That
In The First Place.

People never declare themselves as smart ("Not Stupid") have
written Linux, GCC, etc.. I'm using both Linux and GCC, perhaps
you're using both also, or you're using the substitutes of
yourself. Can you show us some of you smart softwares? Have you got
users for them in c.l.c?

Do you think people in C standard committee all are more stupid than
you and provide you such a stupid broken feature?

lovecreatesbeauty

 

[Frederick Gotham]

Tom St Denis posted:

if (result1 && result2) DoSomething();

My intention was not to execute "DoSomething" if both were true, but rather
if both were the same. Thus in C++, we have:


if ( result1 == result2 ) DoSomething();


But to make this work in C, you'd need:


if( result1 && result2 || !(result1 || result2) ) DoSomething();

 

[lovecreatesbeauty]

Try compiling a program that uses two libraries, both of which define
"true", "false", and "bool", but with incompatible definitions of
"bool".

Most of things in C (library) fail if this happens.

 

[Richard Heathfield]

lovecreatesbeauty said:

A whole C source file in a well format and without typo can't
certainly be supposed as quality code. Do you agree?

I don't know, since I don't know what you're talking about.

What I meant was even a single int i; or int arr[1] like those in the
following small snippet has a chance to fail.

The C Standard guarantees that you can have at least one object at least
32767 (in C90) or 65535 (in C99) bytes in size.

Do you think people in C standard committee all are more stupid than
you and provide you such a stupid broken feature?

I don't think the ISO C committee members are stupid, but I do think they're
human, and they are certainly capable of making mistakes - as C99 shows
very clearly.

 

[Richard Heathfield]

Frederick Gotham said:

Tom St Denis posted:




My intention was not to execute "DoSomething" if both were true, but
rather if both were the same. Thus in C++, we have:


if ( result1 == result2 ) DoSomething();


But to make this work in C, you'd need:


if( result1 && result2 || !(result1 || result2) ) DoSomething();

No, you can do:

if(!!result1 == !!result2) DoSomething();

 

[santosh]

lovecreatesbeauty said:

Keith Thompson wrote:

My problem with VLAs
is that they let you allocate an arbitrary amount of memory during
execution with no mechanism for detecting or handling an allocation
error.

The language (with the revised standard) manages it and guarantees the
memory allocation for VLAs, normal arrays, ints and doubles.

Up to a point.

It is promising it, right?

No, it promises you can definitely have /one/ object 65535 bytes in size.

Do you worry if this fails: Char arr[999999];

It doesn't even compile. And if it did, it isn't guaranteed to succeed.

A whole C source file in a well format and without typo can't
certainly be supposed as quality code. Do you agree?

Indeed, just as stringing words together can be considered as proper
English.
You might try being less philosophical and more lucid.

What I meant was even a single int i; or int arr[1] like those in the
following small snippet has a chance to fail.

No. Static allocation cannot fail. If it fails, the system would not
even load your executable and you'd probably be in serious trouble.
That happens only when you're out memory. This has nothing to do with
the C program or the compiler but rather the runtime condition of the
target system.

(Perhaps this example can
not demonstrate the dangerous. People with wisdom like you, Mr.
Heathfield may do it, don't you?). You pay attention to VLA, you also
pay attention to int i, it's great.

You should *really* try to be more lucid.

People never declare themselves as smart ("Not Stupid") have
written Linux, GCC, etc.. I'm using both Linux and GCC, perhaps
you're using both also, or you're using the substitutes of
yourself. Can you show us some of you smart softwares? Have you got
users for them in c.l.c?

You've completely missed the point that Richard was making. He said
that he won't use constructs which are likely to fail. This has nothing
to do with Richard's smartness, but rather, is a trait of any good
programmer.

BTW, Richard has coauthored a well respected book on C. It called 'C
Unleashed'. Maybe you should look over it sometime before casting
aspersions on his intelligence.

Do you think people in C standard committee all are more stupid than
you and provide you such a stupid broken feature?

I understand that you're not a native English speaker, but you've
*completely* misunderstood the meaning of Richard's post. Try to first
improve you English comprehension and writing skills before posting too
many more posts.