A C showstopper

[Chris McDonald]

It isn't, but I know that the two Chris' are >this< close to
being temporarily killfiled because all I ever see from them
are responses to Ed Bilges. (The other one's worse, though,
if that makes you feel happy.)

That's fine - bye Phil.
Sorry, but I don't wish to be the target of Ed's bilious abuse
in a public forum.

 

[Ben Bacarisse]

(e-mail address removed) (Richard Harter) writes:

About, I think, asprintf:

I checked the gnu implmentation and they do the double evaluation
also. There's simply clay feet everywhere.

There is a twisty maze of function calls involved so I am not entirely
sure what is going on in glibc. What is this double evaluation that
is a sign of clay feet?

I don't think you can be talking about the rather crude double
evaluation problem that a macro would introduce, but neither does it
seem to be the more subtle problem of a value that formats differently
on two occasions despite the value itself not changing (for example a
pointer to a volatile static string that changes over time).

 

[Tom St Denis]

You're going to have to malloc the table. If it is unbounded in the
general case, and it is, you're going to need to use malloc and
remalloc to expand it.

My goal is to stay withing the Unfriendly Confines of the C machine,
aka the C Nightmare. Truly heroic in my case, since I hate C. Rather
like Parsival inside Klingsor's unholy realm.

I was telling myself I was going to stay out of clc for a while but
alas here I am ...

I have a few questions for you

1) Why are you writing an application with unbounded input lengths?
In 99% of all applications it's sufficient to set limits on inputs
making this moot. What sort of strings are you processing that you
absolutely can't set an upper limit on?

2) Why is a two pass solution so bad?

3) w.r.t. having to use realloc/malloc/free/etc what do you think your
$FAVOURITE_LANGUAGE does anyways? You don't think Java doesn't just
behind the scenes realloc the memory it allocated once you concatenate
more data? How do you think computers work and why do you think this
is limited to C?

4) Why are you against writing a library that does the realloc/etc
behind the scenes and then just write applications that call your
library? And why would that be a sign that C is bad?

5) Why do we care?

Tom

 

[Keith Thompson]

That's fine - bye Phil.
Sorry, but I don't wish to be the target of Ed's bilious abuse
in a public forum.

The only way to avoid that is to ignore him. You *will* be the
target of his abuse if you keep responding to him. I don't wish
to be the target of a nest of hornets; it doesn't follow that I
should poke it with a stick.

 

[Nick Keighley]

You're going to have to malloc the table. If it is unbounded in the
general case, and it is, you're going to need to use malloc and
[realloc] to expand it.

My goal is to stay [within] the

....C language

I was telling myself I was going to stay out of clc for a while but
alas here I am ...

I have a few questions for you

1) Why are you writing an application with unbounded input lengths?

he isn't he's writing a general purpose libray. (Almost) unbounded
strings,
arrays tables etc. are nice to write your application in terms of.
Your application may be bounded (are you sure though?) but a library
cannot be. I think its written into the GNU programming standards
that there should be no arbitary limits.

In 99% of all applications it's sufficient to set limits on inputs
making this moot.  What sort of strings are you processing that you
absolutely can't set an upper limit on?

he does seem to making life difficult for himself. I'm guessing a text
editor
for NASA sized data sets.

2) Why is a two pass solution so bad?

because you do two passes... It is two passes of printf which is a
little
language all of its own. The malloc()s may drown the printf()s (but
they
may not- we need measurements or analysis).

3) w.r.t. having to use realloc/malloc/free/etc what do you think your
$FAVOURITE_LANGUAGE does [anyway]?

call malloc I expect. The point is *I* don't have to call malloc()
(or free() more to the point).

 You don't think Java doesn't just
behind the scenes realloc the memory it allocated once you concatenate
more data?  

I'm sure Jave behaves in a similar fashion to $FAVOURITE_LANGUAGE

How do you think computers work[?]

tiny tiny little elves carry bits around. Which are really small bits
of
electricity. Electricity is a sort of blueish fluff.

and why do you think this is limited to C?

Real Men punch their own cards and single step at the console.
It you can't understand self modifying code you don't belong at the
console.

4) Why are you against writing a library that does the realloc/etc
behind the scenes and then just write applications that call your
library?  And why would that be a sign that C is bad?

5) Why do we care?

his thesis is that he has to write the library whilst in
OTHER_LANGUAGE
it would be written for him. This is the argument for all computer
languages. He just thinks C is a particularly poor language. After
he's said
that once everything else is just trolling.

Oh and Spinoza. and already read your calling-me-a-troll-is-equivalent-
to-anti-sematism.
It's crap.

 

[Dik T. Winter]

> I covered that as C99's answer. C99's answer is no good. You replace
> the possibility of memory overwrites with the possibility of something
> that can be EVEN WORSE.
>
> This is the error no-one sees, where an snprintf truncates silently.

What is the return value if you tell it the buffer size is 0?
Moreover, the truncation is certainly not silently, the return value
is there not for nothing.

 

[Rui Maciel]

I covered that as C99's answer. C99's answer is no good. You replace
the possibility of memory overwrites with the possibility of something
that can be EVEN WORSE.

How, exactly? The snprintf() function only truncates it's output if the programmer sets it's buffer size
smaller than the length of the string being passed to it. As the buffer size represents the string's maximum
acceptable length, if snprintf() truncates anything then it was due to the programmer's incompetence and not
due to a library and much less a language problem.

<snip dramatic nonsense>


Rui Maciel

 

[Rui Maciel]

I believe that is what he was referring to with "The C99 solution
(limit the number of characters) is extraordinarily poor ..."

....which doesn't make any sense and apparently was only mentioned to be able to launch personal attacks.


Rui Maciel

 

[Rui Maciel]

(Sigh). How do you know the size of the "buffer" you do need?

Please provide an example where the programmer doesn't know the size of the string that he must pass to
snprintf().



Rui Maciel

 

[jacob navia]

A simple implementation makes two passes over the arguments. The
first determines the length of the formatted output string.
Space is then allocated for a buffer to hold the string. Then a
second pass is made to write the formatted output string into the
buffer.

The catch is that the formatted strings determined by the two
passes don't have to be the same. The arguments are expressions
that can be differ in content and size from pass 1 to pass 2.
For example:

asprintf(char ** buffer,"%s\n",fortune_cookie());

where fortune_cookie() returns a different cookie each time it is
called.

No, in this case it will be evaluated once: when asprintf is
called.

I just can't understand what happens with you today.

Did you drank your coffee? You seem asleep.


lcc-win implements asprintf, as many other compilers do.
It is a pity that the C99 committee did not
standardize existing practice. It is a very practical function.

 

[Chris M. Thomasson]

I have an off-by-one error; this should be
p = malloc(len + 1);

I attempted to emulate `asprintf()' in a pre-C99 environment here:


http://clc.pastebin.com/f63d41ab5


I was wondering if I am misusing the varargs in the function `my_asprintf()'
in any way that might get me into undefined behavior land? Please note that
I have fairly limited experience with them and probably missed something
important!

;^o



Thanks.

 

[Chris M. Thomasson]

[more of the same]
Just grow up Ed, else we'll all treat you like the trolling fool
that you are.

Chris, what exactly is stopping you from treating him like the
trolling fool that he is now?

He's not going to change his behavior. You can. Please stop
feeding the troll.

Ed trolling to hear the sound of his own voice is one thing,
but Ed's throwing hissy fits and abusing people is another.

One is best ignored, and the other is best ignored?
Not seeing a difference there.

Sorry Keith, but it's not your newsgroup, either.

It isn't, but I know that the two Chris' are >this< close to
being temporarily killfiled because all I ever see from them
are responses to Ed Bilges. (The other one's worse, though,
if that makes you feel happy.)

I think I have the right to respond to spinoza1111. If that get's me
killfiled, well, shi% happens.

;^/

 

[Keith Thompson]

A simple implementation makes two passes over the arguments. The
first determines the length of the formatted output string.
Space is then allocated for a buffer to hold the string. Then a
second pass is made to write the formatted output string into the
buffer.

The catch is that the formatted strings determined by the two
passes don't have to be the same. The arguments are expressions
that can be differ in content and size from pass 1 to pass 2.
For example:

asprintf(char ** buffer,"%s\n",fortune_cookie());

where fortune_cookie() returns a different cookie each time it is
called.

Unless asprintf is a macro, it's not going to call fortune_cookie()
more than once.

Then again, "char **buffer" isn't a valid argument unless it is a
macro -- but the GNU asprintf is just a variadic function.

 

[Ben Bacarisse]

A simple implementation makes two passes over the arguments.

It seems you are claiming that glibc uses such a simple implementation
but when I looked i could not see any evidence for two passes. I
accept that I got lost in the maze of function that implement the
printf family so I may have missed something. Can you point to the
code that shows glibc's clay feet in this matter?

Maybe you did not mean glibc when you said GNU. There is a lot of GNU
code after all...

The
first determines the length of the formatted output string.
Space is then allocated for a buffer to hold the string. Then a
second pass is made to write the formatted output string into the
buffer.

The catch is that the formatted strings determined by the two
passes don't have to be the same. The arguments are expressions
that can be differ in content and size from pass 1 to pass 2.
For example:

asprintf(char ** buffer,"%s\n",fortune_cookie());

where fortune_cookie() returns a different cookie each time it is
called.

That (presumably) is because you assume a macro implementation of
asprintf that references the argument list more than once. glibc does
use a macro but not in that way (it simply makes asprintf and call to
some internal __IO_xxx function). Were you looking at a very old
implementation or did I misunderstand the code?

 

[jacob navia]

Please provide an example where the programmer doesn't know the size of the string that he must pass to
snprintf().



Rui Maciel

void LogError(char *ErrorMessage,int errorcode, char *callingFunction)
{
// Here you do not know anything about the length of the arguments
}

 

[Ben Bacarisse]

I wouldn't be surprised if it were one of those three sided
things with constant radius.

I can't decide if this is an in-joke for mathematicians or if you
intended to write "diameter" rather than "radius".

 

[Flash Gordon]

The buffer size as was, yes. However, a signal handler's
changed the first char pointed to by argN from a '\0' to a ' '
in the meantime... ;-)

The signal handler could mess you up during a call to printf...
buffer initially contains "123\0"
printf gets as far as printing "12"
signal handler changes buffer to "1\0XX"
Oops, printf wanders off in to the wild blue yonder despite the buffer
being printed with %s always containing a valid string (followed by some
garbage).

Oh, and the signal handler is padding the buffer with X because it
should only contain digits and this makes it easy to see corruption... ;-)

The moral being that when dealing with memory that might be written to
by a signal handler you need to use volatile sig_atomic_t or implement
some form of locking (in a generic sense, not a specific sense). If you
don't do that you are bound to get strange and unusual problems.

 

[Flash Gordon]

No, in this case it will be evaluated once: when asprintf is
called.

I just can't understand what happens with you today.

Did you drank your coffee? You seem asleep.

The same would apply to a user written implementation of asprintf using
vsnprintf.

lcc-win implements asprintf, as many other compilers do.
It is a pity that the C99 committee did not
standardize existing practice. It is a very practical function.

I would have more use for a slightly different function, one where you
pass in a pointer to a pointer to a malloc'd block which it then expands
if necessary. reasprintf?

It's not hard to implement, so I'm not bothered. I would have no
objection to it being added.

 

[lawrence.jones]

There can be a "downside" to Hungarian notation. This is very contrived
example of course but it could possibly happen. Think of prefixing a bunch
of signed int variables with 'int' (e.g., `intMyVar'). Then for whatever
reason you decide to change them to unsigned variables. Well, you're going
to have to change every variable name's prefix to `uint' or something that
represents the variables unsigndness, so to speak.

Although quite common, that's a complete misuse of Hungarian notation.
The fundamental idea was to use *high level* data types like length,
temperature, and person, not low level data types like int and double.
The data type was supposed to be the used for variable name with
prefixes for things like "pointer to" or "array of", and suffixes only
where necessary to distinguish multiple variables of the same type in
the same scope.

 

[Charlton Wilbur]

troll> As I have said, the grammar of "troll" is isomorphic to "Jew"
troll> in anti- Semitic tracts.

You mean that the *usage* of "troll" is analogous to "Jew"; however, in
that, you're wrong. "Jew" describes an essential quality of a person,
whether ethnicity or religion, while "troll" describes a style of
anti-social behavior.

troll> It derives from Nordic racist texts,

It doesn't, actually; it derives from the verb "to troll," as in for
fish, by dangling a line with one or more baited hooks and waiting for
the fish to bite. The fact that it has a double meaning, in that it
also refers to a repulsive creature that hides below bridges, probably
accounts for its longevity, but it's not the original source.

troll> and it fulfills here the function of racism: unifying the
troll> community against the outsider, no matter how that outsider
troll> is marked...here by his ability to write above a small lower
troll> bound of complexity in an unusual combination with
troll> programming skill somewhat above the norm, and the fact that
troll> he was programming C when you were shitting your pants.

You flatter yourself overmuch.

Charlton