is variant-length array declaration standard compatible?

[bingfeng]

Hi, everyone,
Is the following code

<CODE>
void foo(int n)
{
int a[n];
.....
}
</CODE>

standard compliant and portable?

I use intel's, M$'s, borland's Digital Mars's and GUN(c89)'s compiler
compiled it, the first three report error but the last two were passed
silently. I want to know whether that code is portable.

Ths in advance.
£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£* £*£*
Best regards,

[jacob navia]

bingfeng wrote:

Hi, everyone,
Is the following code

<CODE>
void foo(int n)
{
int a[n];
.....
}
</CODE>

standard compliant and portable?

I use intel's, M$'s, borland's Digital Mars's and GUN(c89)'s compiler
compiled it, the first three report error but the last two were passed
silently. I want to know whether that code is portable.

Ths in advance.
£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£*£* £*£*
Best regards,

This is defined in the C99 standard, and it is portable as long as you
use a C99 compiler.
To use it with gcc use the std=C99 option, if my memory doesn't betray
me.

jacob

[Richard Bos]

"bingfeng" <zh***********@topsec.com.cn> wrote:

void foo(int n)
{
int a[n];
.....
}

standard compliant and portable?

I use intel's, M$'s, borland's Digital Mars's and GUN(c89)'s compiler
compiled it, the first three report error but the last two were passed
silently.

It's correct C99, not C89. It's a Ganuck extension to C89, IIRC; don't
know about Digital Mars. If you want to stay with C89, then no, it's not
portable.

Richard

[CBFalconer]

bingfeng wrote:

Is the following code

<CODE>
void foo(int n)
{
int a[n];
.....
}
</CODE>

standard compliant and portable?

I use intel's, M$'s, borland's Digital Mars's and GUN(c89)'s
compiler compiled it, the first three report error but the last
two were passed silently. I want to know whether that code is
portable.

At least in the GNU case you misused the compiler. It needs -ansi
-pedantic, and usefully also -W -Wall, to properly compile C.
Otherwise it compiles a mishmash of extensions.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Keith Thompson]

CBFalconer <cb********@yahoo.com> writes:
[...]

At least in the GNU case you misused the compiler. It needs -ansi
-pedantic, and usefully also -W -Wall, to properly compile C.
Otherwise it compiles a mishmash of extensions.

Or replace "-ansi" with "-std=c99" to compile a substantial subset of
C99.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Martin Ambuhl]

bingfeng wrote:

Hi, everyone,
Is the following code

<CODE>
void foo(int n)
{
int a[n];
.....
}
</CODE>

standard compliant and portable?
No. '.....' is not a legal statement of any sort.
I use intel's, M$'s, borland's Digital Mars's and GUN(c89)'s compiler
compiled it,

I don't believe you.

[Randy Howard]

In article <ln************@nuthaus.mib.org>, ks***@mib.org says...

CBFalconer <cb********@yahoo.com> writes:
[...]

At least in the GNU case you misused the compiler. It needs -ansi
-pedantic, and usefully also -W -Wall, to properly compile C.
Otherwise it compiles a mishmash of extensions.

Or replace "-ansi" with "-std=c99" to compile a substantial subset of
C99.

Why bother? If you want portable C, you don't write anything containing
C99 extensions. Maybe that will change someday. In the meantime,
there isn't a lot you can't do with good old C89/90.
--
Randy Howard (2reply remove FOOBAR)
"I don't really care about being right you know,
I just care about success." --Steve Jobs

[Denis Bueno]

Randy Howard <ra*********@FOOverizonBAR.net> writes:

In article <ln************@nuthaus.mib.org>, ks***@mib.org says...

CBFalconer <cb********@yahoo.com> writes:
[...]

> At least in the GNU case you misused the compiler. It needs -ansi
> -pedantic, and usefully also -W -Wall, to properly compile C.
> Otherwise it compiles a mishmash of extensions.

Or replace "-ansi" with "-std=c99" to compile a substantial subset of
C99.

Why bother? If you want portable C, you don't write anything containing
C99 extensions. Maybe that will change someday. In the meantime,
there isn't a lot you can't do with good old C89/90.

Since your claim involves some implicited definition of "a lot", I won't
claim to refute you. But, whatever the drawbacks, there are some very nifty
thing you /can/ do with C99 extensions, that you can't in C89.

In particular, you can do things like:

---------------------------------------------
#define WITH_MUTEX_LOCK(l) \
for (int WITH_MUTEX_LOCK_ret = (0 == pthread_mutex_lock(l)); \
WITH_MUTEX_LOCK_ret; \
WITH_MUTEX_LOCK_ret = 0, (void) pthread_mutex_unlock(l)) \

/* code ... */

void
foo (void) {
WITH_MUTEX_LOCK (lock) {
/* locked code */
}
}
---------------------------------------------

Or:

---------------------------------------------
#define WITH_OPEN_FILE(svar, file, mode) /* body */ \
for (void * svar = (void *) fopen(file, mode), * once_only = (void *) 1; \
once_only; \
fclose((FILE *) svar), once_only = (void *) 0)

void
foo (void) {
WITH_OPEN_FILE (stream, "/dev/random", "r") {
/* declarations */
fread(longdata, sizeof(long), 15, stream);
}
}
----------------------------------------------

These sorts of macros make (IMO) source code much more readable, mistakes
less likely (e.g. "Too many open files" if you're fopen()ing in a loop),
and mistake fixes more localized.

Code following this idiom can be multiplied ... but only because of the
ability to declare new variable within the initialize step of the for loop:
a C99 feature.

-Denis

[Jean-Claude Arbaut]

Le 13/06/2005 22:43, dans m2************@taggart.local, «*Denis Bueno*»
<De*********@gtri.gatech.edu> a écrit*:

These sorts of macros make (IMO) source code much more readable, mistakes
less likely (e.g. "Too many open files" if you're fopen()ing in a loop),
and mistake fixes more localized.

Code following this idiom can be multiplied ... but only because of the
ability to declare new variable within the initialize step of the for loop:
a C99 feature.

-Denis

What about this ?

#define WITH_MUTEX_LOCK(l) \
int WITH_MUTEX_LOCK_ret; \
for (WITH_MUTEX_LOCK_ret = (0 == pthread_mutex_lock(l)); \
WITH_MUTEX_LOCK_ret; \
WITH_MUTEX_LOCK_ret = 0, (void) pthread_mutex_unlock(l))

void foo(void) {
{
WITH_MUTEX_LOCK(lock) {
/* locked code */
}
}
}

It seems only slighlty less readable...

[Denis Bueno]

Jean-Claude Arbaut <je****************@laposte.net> writes:

#define WITH_MUTEX_LOCK(l) \
int WITH_MUTEX_LOCK_ret; \
for (WITH_MUTEX_LOCK_ret = (0 == pthread_mutex_lock(l)); \
WITH_MUTEX_LOCK_ret; \
WITH_MUTEX_LOCK_ret = 0, (void) pthread_mutex_unlock(l))

void foo(void) {
{
WITH_MUTEX_LOCK(lock) {
/* locked code */
}
}
}

It seems only slighlty less readable...

Consider, with your definition of WITH_MUTEX_LOCK:

WITH_MUTEX_LOCK (mutex) {
// stuff
}
// stuff
WITH_MUTEX_LOCK (mutex) {
// stuff
}

That code, if I'm not mistaken, will give you a compile error. You need an
independent scope for the macro expansions.

Also, if for any reason you (accidentally) refer to WITH_MUTEX_LOCK_ret
(typo, or whatever) outside of the WITH_MUTEX_LOCK (l) { ... } block, you
will capture whatever garbage is in the variable declared by the
macro. This behavior /completely/ violates the semantics of the block
structure.

Although with my version the code inside the block can capture the
WITH_MUTEX_LOCK_ret variable (which is because there is no way to generate
unique variable names automatically in C), it doesn't violate the semantics
of the block structure, and it doesn't cause the compiler to barf if the
macro is used twice in the same scope.

-Denis
Remove dvorak-noise from From.

[Jean-Claude Arbaut]

Le 17/06/2005 03:29, dans m2************@taggart.local, «*Denis Bueno*»
<db********@UEOAgmail.com> a écrit*:

Jean-Claude Arbaut <je****************@laposte.net> writes:

#define WITH_MUTEX_LOCK(l) \
int WITH_MUTEX_LOCK_ret; \
for (WITH_MUTEX_LOCK_ret = (0 == pthread_mutex_lock(l)); \
WITH_MUTEX_LOCK_ret; \
WITH_MUTEX_LOCK_ret = 0, (void) pthread_mutex_unlock(l))

void foo(void) {
{
WITH_MUTEX_LOCK(lock) {
/* locked code */
}
}
}

It seems only slighlty less readable...
Consider, with your definition of WITH_MUTEX_LOCK:

WITH_MUTEX_LOCK (mutex) {
// stuff
}
// stuff
WITH_MUTEX_LOCK (mutex) {
// stuff
}

That code, if I'm not mistaken, will give you a compile error. You need an
independent scope for the macro expansions.

That's why I put curly braces around !
Also, if for any reason you (accidentally) refer to WITH_MUTEX_LOCK_ret
(typo, or whatever) outside of the WITH_MUTEX_LOCK (l) { ... } block, you
will capture whatever garbage is in the variable declared by the
macro.
It simply should never happen. It suffices to remember the outer {...} block
can only contain one macro expansion and nothing else. I use it merely to
be able to declare a local variable with a name common to all macros.
This behavior /completely/ violates the semantics of the block
structure.
I'm not sure, but I'm not sure you are wrong either :-)
Although with my version the code inside the block can capture the
WITH_MUTEX_LOCK_ret variable (which is because there is no way to generate
unique variable names automatically in C), it doesn't violate the semantics
of the block structure, and it doesn't cause the compiler to barf if the
macro is used twice in the same scope.

I was just trying to show you C99 is not absolutely needed for that trick.

[Jean-Claude Arbaut]

I was just trying to show you C99 is not absolutely needed for that trick.

Anyway, even if mine works, your solution is more elegant.

[Me]

<snip nifty tricks about C99>

#define WITH_OPEN_FILE(svar, file, mode) /* body */ \
for (void * svar = (void *) fopen(file, mode), * once_only = (void *) 1; \
once_only; \
fclose((FILE *) svar), once_only = (void *) 0)

void
foo (void) {
WITH_OPEN_FILE (stream, "/dev/random", "r") {
/* declarations */
fread(longdata, sizeof(long), 15, stream);
}
}

<snip>

Change once_only's initializer to &svar (and get rid of all the (void*)
casting), otherwise it's not guaranteed what (void*)1 will return when
being evaluated for a truth value. Infact, I'd probably rewrite it as
the following since the above doesn't handle fopen failing:

#define WITH_OPEN_FILE(svar, file, mode) \
for (FILE *svar = fopen(file, mode); svar; fclose(svar), svar = 0)

In C++, this would be much better because it allows initializers in
conditionals. That feature combined with destructors lets you could do:

if (file_t file = create_file(name, mode)) {
// read file
} else {
// handle failure
}

And not let the break/return statement accidentally leak a filehandle.
But, I'm already off-topic for this newsgroup.