On Sun, 1 Mar 2015 23:02:00 -0800
Michael Forney wrote:
Hey Michael,
> So I think we need to do
>
> if (!(rm_fflag && errno == ENOENT))
> rm_status = 1;
>
> instead of
>
> rm_status = !(rm_fflag && errno == ENOENT);
oh yeah, considering how long I've worked with these
flag-games, I
This came up recently in talks about style in sbase due to my
misunderstanding of "Do not mix declarations and code" and subsequent
addition of the line "All variable declarations at top of block" in
the style guide.
It was my understanding that "Do not mix declarations and code" meant
stick to AN
Evan Gates wrote:
> Thoughts?
Heyho,
a suckless piece of code, where this is used would be the manage() function of
tabbed.c. I don't mind it to declare variables in inner blocks, so it is clear
to the reader that this variable is only intended to be used inside this block
and not only the mighty
Evan Gates writes:
> Declaring variables at the top of a block, as opposed to top of the
> function has a few uses, but the most useful (in my limited
> experience) is combining it with C99's variable length arrays to
> create buffers without calls to malloc/free. For example:
>
> while ((d = read
On Mon, Mar 2, 2015 at 3:56 PM, Anthony J. Bentley wrote:
> VLAs are a fundamentally broken feature because they do not allow any
> error checking. alloca() is the same.
>
> --
> Anthony J. Bentley
>
But when do you ever do error checking of stack size? Is recursion a
fundamentally broken feature
Also how strict should the rule be? Is calling functions to define
variables when declaring them considered mixing declarations and code?
i.e. is this allowed?
size_t len = strlen(s);
char *buf = emalloc(len + 1);
etc. etc.
On Mon, Mar 2, 2015 at 3:43 PM, Markus Teich wrote:
> Heyho,
>
> a suc
