Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #60371 > unrolled thread

Please critique my strdupf library

Back to article view | Back to comp.lang.c

Contents

  Please critique my strdupf library samuelallenalexander@gmail.com - 2015-04-19 01:34 -0700
    Re: Please critique my strdupf library Ian Collins <ian-news@hotmail.com> - 2015-04-19 20:46 +1200
      Re: Please critique my strdupf library samuelallenalexander@gmail.com - 2015-04-19 02:25 -0700
        Re: Please critique my strdupf library Ian Collins <ian-news@hotmail.com> - 2015-04-19 21:35 +1200
          Re: Please critique my strdupf library Keith Thompson <kst-u@mib.org> - 2015-04-19 07:44 -0700
            Re: Please critique my strdupf library samuelallenalexander@gmail.com - 2015-04-19 10:23 -0700
              Re: Please critique my strdupf library Morris Dovey <mrdovey@iedu.com> - 2015-04-19 13:09 -0500
        Re: Please critique my strdupf library fir <profesor.fir@gmail.com> - 2015-04-19 02:48 -0700
          Re: Please critique my strdupf library samuelallenalexander@gmail.com - 2015-04-19 03:42 -0700
    Re: Please critique my strdupf library fir <profesor.fir@gmail.com> - 2015-04-19 02:11 -0700
    Re: Please critique my strdupf library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-19 11:11 +0100
      Re: Please critique my strdupf library samuelallenalexander@gmail.com - 2015-04-19 04:36 -0700
        Re: Please critique my strdupf library Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-04-19 15:41 +0200
          Re: Please critique my strdupf library samuelallenalexander@gmail.com - 2015-04-19 07:28 -0700
    Re: Please critique my strdupf library August Karlstrom <fusionfile@gmail.com> - 2015-04-19 12:12 +0200
    Re: Please critique my strdupf library Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-04-19 13:25 +0200
      Re: Please critique my strdupf library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-19 13:32 +0100
    Re: Please critique my strdupf library Lőrinczy Zsigmond <nospam@for.me> - 2015-04-19 16:29 +0200
    Re: Please critique my strdupf library Keith Thompson <kst-u@mib.org> - 2015-04-19 07:52 -0700

#60371 — Please critique my strdupf library

Dear comp.lang.c,

I wrote a tiny little library to implement "strdupf", now I don't know how I ever lived without it.  strdupf is like strdup, except it takes printf-style variadic format arguments instead of a single string argument.

The library is here: https://github.com/semitrivial/mallocf

Please critique the library, in particular I'm concerned about:

* Portability: Have I accidentally relied on anything implementation-dependent?

* Correctness: Have I committed any glaring sins against C?

* Style: Aside from my signature 2-space indents, have I committed any stylistic sins?

Is there anything you can see that would further improve the library?

Thank you!
Sam

[toc] | [next] | [standalone]

#60372

samuelallenalexander@gmail.com wrote:
> Dear comp.lang.c,
>
> I wrote a tiny little library to implement "strdupf", now I don't know how I ever lived without it.  strdupf is like strdup, except it takes printf-style variadic format arguments instead of a single string argument.
>
> The library is here: https://github.com/semitrivial/mallocf
>
> Please critique the library, in particular I'm concerned about:
>
> * Portability: Have I accidentally relied on anything implementation-dependent?
>
> * Correctness: Have I committed any glaring sins against C?
>
> * Style: Aside from my signature 2-space indents, have I committed any stylistic sins?
>
> Is there anything you can see that would further improve the library?

What is the reason for the macros at the top of mallocf.c?  va_copy and 
va_end are standard.

One classic: sizeof(char) is one by definition.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#60374

On Sunday, April 19, 2015 at 9:46:39 AM UTC+1, Ian Collins wrote:
> samuel wrote:
> > Dear comp.lang.c,
> >
> > I wrote a tiny little library to implement "strdupf", now I don't know how I ever lived without it.  strdupf is like strdup, except it takes printf-style variadic format arguments instead of a single string argument.
> >
> > The library is here: https://github.com/semitrivial/mallocf
> >
> > Please critique the library, in particular I'm concerned about:
> >
> > * Portability: Have I accidentally relied on anything implementation-dependent?
> >
> > * Correctness: Have I committed any glaring sins against C?
> >
> > * Style: Aside from my signature 2-space indents, have I committed any stylistic sins?
> >
> > Is there anything you can see that would further improve the library?
> 
> What is the reason for the macros at the top of mallocf.c?  va_copy and 
> va_end are standard.
> 

From my literature review, I got the impression va_copy is rather finicky on pre-C99, see the bottom section here:
http://www.gnu.org/software/libc/manual/html_node/Argument-Macros.html

I guess I should mention that in a comment, thank you for the pointer.


On Sunday, April 19, 2015 at 10:11:25 AM UTC+1, fir wrote:

> nothing to say to it.. i dislike the macros, are they needed..? to small for library..
> it seems for me that library should have sane 
> size not to big also not to small (probably if to big it is better to provide a couple of libraries instead the one.. though im not sure)
> 
> could you say what compiler and what make you use here?

I thought about adding some macros for 'automatically' turning arbitrary functions into variadic formatted functions, so for example if you had a function void error_message(char*x), you could call some macros to automatically get a function void error_messagef(char*x,...)  But it seemed like that would increase the cognitive investment required too much for too little gain (as well as increasing the surface area for accidental unportability)

Any suggestions for what I could add to the library to beef it up bigger?

P.S. You'd hate the javascript community, those guys are crazy, they literally publish a whole "library" for, e.g., a function that checks whether the input string is lowercase.

[toc] | [prev] | [next] | [standalone]

#60375

samuelallenalexander@gmail.com wrote:
> On Sunday, April 19, 2015 at 9:46:39 AM UTC+1, Ian Collins wrote:
>> samuel wrote:
>>> Dear comp.lang.c,
>>>
>>> I wrote a tiny little library to implement "strdupf", now I don't know how I ever lived without it.  strdupf is like strdup, except it takes printf-style variadic format arguments instead of a single string argument.
>>>
>>> The library is here: https://github.com/semitrivial/mallocf
>>>
>>> Please critique the library, in particular I'm concerned about:
>>>
>>> * Portability: Have I accidentally relied on anything implementation-dependent?
>>>
>>> * Correctness: Have I committed any glaring sins against C?
>>>
>>> * Style: Aside from my signature 2-space indents, have I committed any stylistic sins?
>>>
>>> Is there anything you can see that would further improve the library?
>>
>> What is the reason for the macros at the top of mallocf.c?  va_copy and
>> va_end are standard.
>>
>
>  From my literature review, I got the impression va_copy is rather finicky on pre-C99, see the bottom section here:
> http://www.gnu.org/software/libc/manual/html_node/Argument-Macros.html
>
> I guess I should mention that in a comment, thank you for the pointer.

Well I was using them in the mid 80's, so I guess there might be really 
old compilers that don't have them.  I wouldn't bother looking back that 
far!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#60413

Ian Collins <ian-news@hotmail.com> writes:
> samuelallenalexander@gmail.com wrote:
[...]
>>  From my literature review, I got the impression va_copy is rather
>> finicky on pre-C99, see the bottom section here:
>> http://www.gnu.org/software/libc/manual/html_node/Argument-Macros.html
>>
>> I guess I should mention that in a comment, thank you for the pointer.
>
> Well I was using them in the mid 80's, so I guess there might be
> really old compilers that don't have them.  I wouldn't bother looking
> back that far!

va_start, va_arg, and va_end go babck to C89/C90.  va_copy was
introduced in C99.  There could be compilers that don't support it.
(Microsoft's compiler is the usual suspect for this kind of thing,
but apparently it does support it.)

I haven't studied the code; I wonder if you can modify it to avoid
using va_copy (if you care about pre-C99 portability).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#60441

Keith Thompson/Lőrinczy Zsigmond wrote:
>vasprintf

Embarrassing!  It's still useful to have a form which returns char * instead of writing result to user-supplied char **.  I guess I'll modify the library to use GNU's (presumably heavily optimized) vasprintf implementation to do the work if possible, and advertise the library as a portability wrapper...


Keith Thompson wrote:
> 
> I haven't studied the code; I wonder if you can modify it to avoid
> using va_copy (if you care about pre-C99 portability).
> 

It could be done by examining fmt and working out the % codes from scratch.  I hesitate to do this is I assume standard library functions must be optimized to death with asm/implementation-specific wizardry/custom silicon/etc.  Am I wrong about that?

Keith Thompson wrote:
>
> str followed by lowercase is reserved
>

Troubling.  Thanks for bearing bad news, I appreciate it.

Regards,
Sam

[toc] | [prev] | [next] | [standalone]

#60446

On 4/19/15 12:23 PM, samuelallenalexander@gmail.com wrote:

> Keith Thompson wrote:
>
>> >str followed by lowercase is reserved
>
> Troubling.  Thanks for bearing bad news, I appreciate it.

I got a lot of that bad news. I went through my collection and changed 
the names for my functions from str* to rts*. :-)

-- 
Morris Dovey
http://www.iedu.com/Solar

[toc] | [prev] | [next] | [standalone]

#60377

W dniu niedziela, 19 kwietnia 2015 11:25:25 UTC+2 użytkownik samuelalle...@gmail.com napisał:
> On Sunday, April 19, 2015 at 9:46:39 AM UTC+1, Ian Collins wrote:
> > samuel wrote:
> > > Dear comp.lang.c,
> > >
> > > I wrote a tiny little library to implement "strdupf", now I don't know how I ever lived without it.  strdupf is like strdup, except it takes printf-style variadic format arguments instead of a single string argument.
> > >
> > > The library is here: https://github.com/semitrivial/mallocf
> > >
> > > Please critique the library, in particular I'm concerned about:
> > >
> > > * Portability: Have I accidentally relied on anything implementation-dependent?
> > >
> > > * Correctness: Have I committed any glaring sins against C?
> > >
> > > * Style: Aside from my signature 2-space indents, have I committed any stylistic sins?
> > >
> > > Is there anything you can see that would further improve the library?
> > 
> > What is the reason for the macros at the top of mallocf.c?  va_copy and 
> > va_end are standard.
> > 
> 
> From my literature review, I got the impression va_copy is rather finicky on pre-C99, see the bottom section here:
> http://www.gnu.org/software/libc/manual/html_node/Argument-Macros.html
> 
> I guess I should mention that in a comment, thank you for the pointer.
> 
> 
> On Sunday, April 19, 2015 at 10:11:25 AM UTC+1, fir wrote:
> 
> > nothing to say to it.. i dislike the macros, are they needed..? to small for library..
> > it seems for me that library should have sane 
> > size not to big also not to small (probably if to big it is better to provide a couple of libraries instead the one.. though im not sure)
> > 
> > could you say what compiler and what make you use here?
> 
> I thought about adding some macros for 'automatically' turning arbitrary functions into variadic formatted functions, so for example if you had a function void error_message(char*x), you could call some macros to automatically get a function void error_messagef(char*x,...)  But it seemed like that would increase the cognitive investment required too much for too little gain (as well as increasing the surface area for accidental unportability)
> 
> Any suggestions for what I could add to the library to beef it up bigger?
> 
> P.S. You'd hate the javascript community, those guys are crazy, they literally publish a whole "library" for, e.g., a function that checks whether the input string is lowercase.

ye, probably 

ps could you say what cmpiler and what make?

[toc] | [prev] | [next] | [standalone]

#60383

On Sunday, April 19, 2015 at 10:48:56 AM UTC+1, fir wrote:
> 
> ps could you say what cmpiler and what make?

I'm testing with two different environments,

Environment 1:
Apple LLVM version 6.0 (clang-600.0.56)
GNU Make 3.81

Environment 2:
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
GNU Make 3.81


Ian Collins wrote:
> Well I was using them in the mid 80's, so I guess there might be really
old compilers that don't have them.  I wouldn't bother looking back that
far! 

Alright, it looks like I was being over-cautious, I will remove those macros.  Thanks!

> You have a bug, but it's easy to fix: the vsnprintf function you use to
calculate the length returns int not size_t because it can return a
negative number when an encoding error occurs

Gosh, thanks!

August Karlstrom wrote:
> If I see some code that uses strdupf, say, how can I tell that it's
declared in mallocf.h? 

I didn't really think of that (how does one tell that, e.g., printf is declared in stdio.h, short of already knowing it)?  Maybe I'll look into renaming the library, since strdupf really is the flagship of the library

Regards,
Sam

[toc] | [prev] | [next] | [standalone]

#60373

W dniu niedziela, 19 kwietnia 2015 10:34:24 UTC+2 użytkownik samuelalle...@gmail.com napisał:
> Dear comp.lang.c,
> 
> I wrote a tiny little library to implement "strdupf", now I don't know how I ever lived without it.  strdupf is like strdup, except it takes printf-style variadic format arguments instead of a single string argument.
> 
> The library is here: https://github.com/semitrivial/mallocf
> 
> Please critique the library, in particular I'm concerned about:
> 
> * Portability: Have I accidentally relied on anything implementation-dependent?
> 
> * Correctness: Have I committed any glaring sins against C?
> 
> * Style: Aside from my signature 2-space indents, have I committed any stylistic sins?
> 
> Is there anything you can see that would further improve the library?
> 
> Thank you!
> Sam

nothing to say to it.. i dislike the macros, are they needed..? to small for library..
it seems for me that library should have sane 
size not to big also not to small (probably if to big it is better to provide a couple of libraries instead the one.. though im not sure)

could you say what compiler and what make you use here? 

[toc] | [prev] | [next] | [standalone]

#60378

samuelallenalexander@gmail.com writes:

> I wrote a tiny little library to implement "strdupf", now I don't know
> how I ever lived without it.  strdupf is like strdup, except it takes
> printf-style variadic format arguments instead of a single string
> argument.
>
> The library is here: https://github.com/semitrivial/mallocf
>
> Please critique the library,

You have a bug, but it's easy to fix: the vsnprintf function you use to
calculate the length returns int not size_t because it can return a
negative number when an encoding error occurs.  The result is a huge
length from strlenf and a possible undefined memory access in vstrdupf
(it depends on what negative number is returned and what your malloc
does when passed zero).

Test case: strlenf("%lc", (wchar_t)-1).

It's been mentioned already, but the worry in mallocf.h that va_copy
might be undefined looks odd, given that you rely on the C99 function
vsnprintf.  Have you found a system with one and not the other?

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#60389

On Sunday, April 19, 2015 at 11:12:08 AM UTC+1, Ben Bacarisse wrote:
>
> You have a bug, but it's easy to fix: the vsnprintf function you use to
> calculate the length returns int not size_t because it can return a
> negative number when an encoding error occurs.  The result is a huge
> length from strlenf and a possible undefined memory access in vstrdupf
> (it depends on what negative number is returned and what your malloc
> does when passed zero).
>

What a fly in the ointment.  I updated the library so (v)strlenf returns 0 in case of encoding error and (v)strdupf returns NULL in case of encoding error.  It seems pretty inelegant though, particularly since there's no for a size_t result to communicate error, so I had to make a special utility copy of vstrlenf, vstrlenf_verbose, with an int *err argument.

Is there a smarter strategy I'm missing?  Is it foolish of me to insist on (v)strlenf returning size_t instead of int?

Regards,
Sam

[toc] | [prev] | [next] | [standalone]

#60398

On 19.04.2015 13:36, samuelallenalexander@gmail.com wrote:

> What a fly in the ointment.  I updated the library so (v)strlenf returns 0 in case of encoding error and (v)strdupf returns NULL in case of encoding error.  It seems pretty inelegant though, particularly since there's no for a size_t result to communicate error, so I had to make a special utility copy of vstrlenf, vstrlenf_verbose, with an int *err argument.

I'd avoid returning zero for sure. Consider (Cish pseudocode follows)

void do_print(wchar_t achar) {
	int len = strlenf("That's right! The char is %lc", achar);
	char buffer[len];
	sprintf(buffer, "That's right! The char is %lc", achar);
	print_str(buffer);	
}

If "achar" was a illegal representation then your strlenf returns zero,
the buffer is of size zero and you have a buffer overflow in the sprintf
(which I'm guessing will print everything that comes before the illegal
char).

Just my two cents here.

Cheers,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

#60407

On Sunday, April 19, 2015 at 2:41:09 PM UTC+1, Johannes Bauer wrote:
> 
> I'd avoid returning zero for sure. Consider (Cish pseudocode follows)
> 

You're right.  I bit the bullet and changed the returns to int instead of size_t.  I wonder whether that will significantly reduce the usefulness of those functions (to people expecting size_t returns from strlen-like functions).  Well, the main function strdupf is still good.

Ben Bacarisse wrote:
> Yes, that's neat, but I found the comment in the code rather unclear. 

I've changed the comment to be more accurate, thanks very much for pointing that out.

Regards,
Sam

[toc] | [prev] | [next] | [standalone]

#60379

On 2015-04-19 10:34, samuelallenalexander@gmail.com wrote:
> Dear comp.lang.c,
>
> I wrote a tiny little library to implement "strdupf", now I don't
> know how I ever lived without it.  strdupf is like strdup, except it
> takes printf-style variadic format arguments instead of a single
> string argument.
>
> The library is here: https://github.com/semitrivial/mallocf

If I see some code that uses strdupf, say, how can I tell that it's 
declared in mallocf.h?


-- August

[toc] | [prev] | [next] | [standalone]

#60387

On 19.04.2015 10:34, samuelallenalexander@gmail.com wrote:

> Is there anything you can see that would further improve the library?

No real help here but a comment: I found your use of vsnprintf rather
clever in the way you use it within strlenf. Didn't know that it returns
the number of non-printable characters, but I do now :-)

Cheers,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

#60393

Johannes Bauer <dfnsonfsduifb@gmx.de> writes:

> On 19.04.2015 10:34, samuelallenalexander@gmail.com wrote:

(Aside: did you know you can put .s in gmail addresses without altering
the account to which they refer?  All of abc@gmail.com, a.bc@gmail.com
and a.b.c@gmail.com refer to the same account.)

>> Is there anything you can see that would further improve the library?
>
> No real help here but a comment: I found your use of vsnprintf rather
> clever in the way you use it within strlenf. Didn't know that it returns
> the number of non-printable characters, but I do now :-)

Yes, that's neat, but I found the comment in the code rather unclear.
It says, much like you summary here, that "vsnprintf returns the number
of chars that could not be printed due to size limit".  That's not
literally true (but it made me go check because it sounds so
authoritative!)  vsnprintf returns the number of character that would
need to be printed to do the job, which, if you pass 0 as the buffer
size, does indeed become the number of characters that could not be
printed.

(I hope you won't mind a language correction: the pharse "non-printable
characters" would refer to those with some property -- that of being
inherently non-printable -- not to those that are not printed in some
specific situation.  One could say "the number of not-printed
characters" or, more comfortably, "the number of characters not printed".)

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#60408

Is it something like vasprintf?

[toc] | [prev] | [next] | [standalone]

#60415

samuelallenalexander@gmail.com writes:
> Dear comp.lang.c,
>
> I wrote a tiny little library to implement "strdupf", now I don't know
> how I ever lived without it.  strdupf is like strdup, except it takes
> printf-style variadic format arguments instead of a single string
> argument.
>
> The library is here: https://github.com/semitrivial/mallocf
>
> Please critique the library, in particular I'm concerned about:
>
> * Portability: Have I accidentally relied on anything
>   implementation-dependent?
>
> * Correctness: Have I committed any glaring sins against C?
>
> * Style: Aside from my signature 2-space indents, have I committed any
>   stylistic sins?
>
> Is there anything you can see that would further improve the library?

This looks similar to asprintf() and vasprintf().  (They're GNU
extensions, not defined by the C or POSIX standards.  They're also
available under *BSD.)

Identifiers starting with str and a lowercase letter are reserved.  You
might consider calling it str_dupf.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web