Re: Boost process and C

CBFalconer wrote:
websnarf@xxxxxxxxx wrote:
CBFalconer wrote:
... snip ...
The last time I took an (admittedly cursory) look at Bstrlib, I
found it cursed with non-portabilities

You perhaps would like to name one?

I took another 2 minute look, and was immediately struck by the use
of int for sizes, rather than size_t. This limits reliably
available string length to 32767.

Using size_t is also not any more *portable* than using int. Any lack
of portability is merely a reflection of the lack of the intrinsic
non-portability of the language itself. size_t can only reliably
contain values as high as 65535 -- so you are saying this difference in
limits (between 32k and 64k) embodies a significant universe of string
manipulation to warrant a claim against Bstrlib's portability?

[...] I did find an explanation and
justification for this. Conceded, such a size is probably adequate
for most usage, but the restriction is not present in standard C
strings.

Your going to need to conceed on more grounds than that. There is a
reason many UNIX systems tried to add a ssize_t type, and why TR 24731
has added rsize_t to their extension. (As a side note, I strongly
suspect the Microsoft, in fact, added this whole rsize_t thing to TR
24731 when they realized that Bstrlib, or things like it, actually has
far better real world safety because its use of ints for string
lengths.) Using a long would be incorrect since there are some systems
where a long value can exceed a size_t value (and thus lead to falsely
sized mallocs.) There is also the matter of trying to codify read-only
and constant strings and detecting errors efficiently (negative lengths
fit the bill.) Using ints is the best choice because at worst its
giving up things (super-long strings) that nobody cares about, it
allows in an efficient way for all desirable encoding scenarios, and it
avoids any wrap around anomolies causing under-allocations. If I tried
to use size_t I would give up a significant amount of safety and design
features (or else I would have to put more entries into the header,
making it less efficient).

Hundreds of people have downloaded Bstrlib and seriously looked at it
already. I've gotten plenty of feedback over its lifetime which has
lead to its evolution (so its not like it hasn't already had
significant review). You, of all people, are not going find any
serious flaw in it by perusing it for 2 minutes.

"Cursed with non-portabilities" indeed ...

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

.

Relevant Pages

  • Re: Boost process and C
    ... Using size_t is also not any more *portable* than using int. ... of portability is merely a reflection of the lack of the intrinsic ... I've gotten plenty of feedback over its lifetime which has ... "Cursed with non-portabilities" indeed ... ...
    (comp.lang.c)
  • Re: Boost process and C
    ... Using size_t is also not any more *portable* than using int. ... of portability is merely a reflection of the lack of the intrinsic ... able to create objects bigger than 65535 bytes. ... "Cursed with non-portabilities" indeed ... ...
    (comp.lang.c)
  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... conformant string. ... int repeats, reps; ... ref satisfierLength); ...
    (comp.programming)
  • RE: Controling Modal Dialogs (Solution)
    ... doesn't return until the 'modal' browser returns. ... string varOptions) ... public void DocumentComplete ... int rc = winDisp.Invoke(rgDispId, ref guid, 0, ...
    (microsoft.public.inetsdk.programming.webbrowser_ctl)
  • Gcc compatible header file
    ... A string collection is a table of zero terminated strings that will grow ... typedef struct _StringCollection StringCollection; ... int; ... bool; ...
    (comp.lang.c)