Re: strange behaviour

tfelb wrote:

Thanks! This code is in /pre/ stadium so i know it doesn't have
any security checks

Epic failure!

Security is difficult to add later in existing systems. Always, I
repeat, always design interfaces in a

but i think its better to use a pointer
array as an argument instead of a double pointer.

You mean something like

char *s2[]

? Technically it behaves exactly like char **s2, though at
compilation stage the types subtely differ. However this is
something of interest for compiler writers, the average coder
should know, that the "pointer to pointer" notation is almost
the same as the "array of pointers" notation and is identical,
when it comes to machine language.

Now it works.

It works in if well formulated data is input. A much safer
interface would be:

void join(
unsigned int const dst_buffer_length,
char * const dst_buffer,
char const * const delimiter_string,
unsigned int const src_string_count
char const * const * const src_strings,
);


A even more safer style would completely abandon the use
of "naked" arrays and instead encapsulate every array operation
within bounds checking helper functions. Have a look at Felix
von Leitner's libowfat library: It provides such an array
abstraction - together with things like overflow safe integer
multiplication and other neat stuff.
<http://www.fefe.de/libowfat/>

Just to give you an idea how it works with arrays, this is an
excerpt of "array.h" of libowfat:

#ifndef ARRAY_H
#define ARRAY_H

#include "uint64.h"

typedef struct {
char* p;
int64 allocated; /* in bytes */
uint64 initialized; /* in bytes */

/* p and allocated nonzero: array is allocated */
/* p and allocated zero: array is unallocated */
/* p zero and allocated < 0: array is failed */
} array;

void* array_allocate(array* x,uint64 membersize,int64 pos);
void* array_get(array* x,uint64 membersize,int64 pos);
void* array_start(const array* const x);
int64 array_length(const array* const x,uint64 membersize);
int64 array_bytes(const array* const x);
void array_truncate(array* x,uint64 membersize,int64 len);
void array_trunc(array* x);
void array_reset(array* x);
void array_fail(array* x);
/* ... */

uint64.h is the header to overflow safe multiplication code and
associated types (it wont resort to bignums, if a multiplication
overflows, but such is detected and triggers error handling).
Thow only "drawback" of libowfat is, that it's GPL licenced, so
you can't use it in a closed source project. But you're still
free to have a look at it's code and get inspiration from it.

Wolfgang Draxinger
--
E-Mail address works, Jabber: hexarith@xxxxxxxxxx, ICQ: 134682867

.

Relevant Pages

  • Re: is there an alternative to strstr
    ... >> To exploit this fact, you need a different data format, a plain string is ... > Ok I have put the email ids in a sorted array. ... However you can use an array of char pointers and use ... int cmp(const void *v1, const void *v2); ...
    (comp.lang.c)
  • Re: 2D arrays and addresses
    ... address of the first element of the array with type pointer to element ... The standard requires char* and void* to have the same size ...
    (comp.lang.c)
  • Re: VC++.NET 2003 should not issue C4090 ompiler warning in the following case
    ... Only the cell of the array is of type ... The second actually declares foo to be an array of void* const. ... > typedef const MYTYPE MYCONSTTYPE; ...
    (microsoft.public.vc.language)
  • Re: VC++.NET 2003 should not issue C4090 ompiler warning in the following case
    ... Only the cell of the array is of type ... >const void *. ... >typedef const MYTYPE MYCONSTTYPE; ...
    (microsoft.public.vc.language)
  • Re: Passing Pointers
    ... And now you know why you didn't want to allocate that 100 char array above: ... Note the memory you're deleting was allocated within Input. ... so name now points to a dynamically allocated array of chars. ... >void Output ...
    (alt.comp.lang.learn.c-cpp)