is clang production-ready?

if you compile this code with gcc it will work with no proplem
Code:
#define _WITH_GETLINE
#include<stdio.h>
#include<stdlib.h>
#include<string.h>
#define MAX_FILE 2
void usage(); 
int compare(FILE *fileToCompare[] , int fileNum , char **msg);    
int main(int argc , char *argv[])
{
    FILE *fileToCompare[MAX_FILE];
    int lineNumber; 
    char *line ; 
    size_t line_cap;
    char *msg = NULL; 
    int  n ;
    argc--;
    if(argc != MAX_FILE)
    {
        usage(); 
    }
    while(--argc >= 0)
    {
       fileToCompare[argc]  = fopen(*++argv ,"r" ) ;
       if(!fileToCompare[argc])
        {
            printf("can't open file ");
            exit(1);
        }

    }
    lineNumber = compare(fileToCompare , MAX_FILE , &msg  );
    if(msg)
    {
        int n  = 0 ; 
        int l ; 
        int y ; 
        for (y = MAX_FILE - 1; y >= 0 ; y--)
        { 
            for( l = lineNumber ; l > 1 ; l-- )
            {
                 n = getline(&line , &line_cap , fileToCompare[y]);
         
            }
            if(n > 0)
            {
                fwrite(">>>\n" , 4 , 1 , stdout);
                fwrite(line , n , 1 , stdout);
                fwrite(">>>\n" , 4 , 1 , stdout);
            }
        }
    }
    else
    {
        printf("the both file are equal") ; 
    }

}
void usage()
{
    fprintf(stderr  , "please enter two file to find the first diffrent ? ");
    exit(1);
}
int compare(FILE *fileToCompare[] , int fileNum , char **msg)     
{
    char *errorMsg = "file mismatch at line number %d" ; 
    char cInit = fgetc(fileToCompare[0]) , cOther ;
    int lineNumber = 1 , i ; 
    for(i = 1 ; i < fileNum && cInit != EOF ; i = (i + 1) % fileNum) 
    {
        if(i == 0)
        {
            cInit = fgetc(fileToCompare[i]);
            continue;
        }
        if(cInit == '\n')
            lineNumber++;
        cOther = fgetc(fileToCompare[i]) ;
        if(cOther != cInit)  
        {
            *msg = (char *)malloc(sizeof(char) * (strlen(errorMsg) + 1));
            sprintf(*msg , errorMsg , i); 
            break;
        }
    }
    return lineNumber;
}
but if you compile it with clang it will give segmentation fault
the strange thing if you put
Code:
printf("%d , %d" ,(int) fileToCompare[y] , n);
after getline it will work after compilation with clang really I got many issue with clang but this happend today
 
This is not the correct place to ask. Go to the appropriate mailing lists.

clang/llvm seems to perform better than the archaic gcc 4.2.1. FreeBSD/PC-BSD seem to lack behind debian/ubuntu in most benchmarks due to the old gcc. In fact it is a surprise that FreeBSD wins in some (few) benchmarks. So, you would help if you contacted the right people.
 
darkshadow said:
if you compile this code with gcc it will work with no proplem
Code:
                 n = getline(&line , &line_cap , fileToCompare[y]);
but if you compile it with clang it will give segmentation fault
the strange thing if you put
From the top of my mind (and i did not have any coffee right now) - I think in the first iteration the pointers which are passed to getline are not initialized properly.
 
Crivens said:
From the top of my mind (and i did not have any coffee right now) - I think in the first iteration the pointers which are passed to getline are not initialized properly.

That is true. Buffer needs to be set to NULL and size to 0 before calling it for first time.
 
mm

I will set t to null while I dont know why to do that , since the get line will change it position and allocate memory for it , I will test one I reach home
 
There is an easy explanation why to do that.
The pointer, if not null, will be handed to realloc() which will hand it to free(). If you are lucky, that is. If the length is not set to zero at the beginning, the getline may think it has enough space in the buffer and simply write to the pointer you passed it.
So if you are lucky your code will blow up there and then. If you are unlucky, then getline will simply write all over your process heap area and you may find out about that sometime later - when something somewhere else is corrupted sometimes, correlating with moonphases or beer in the fridge.

Such things are called Heisenbug sometimes.
 
Code:
ssize_t
getdelim(char ** __restrict linep, size_t * __restrict linecapp, int delim,
	 FILE * __restrict fp)
{
	u_char *endp;
	size_t linelen;

	FLOCKFILE(fp);
	ORIENT(fp, -1);

	if (linep == NULL || linecapp == NULL) {
		errno = EINVAL;
		goto error;
	}

	if (*linep == NULL)
		*linecapp = 0;

	if (fp->_r <= 0 && __srefill(fp)) {
		/* If fp is at EOF already, we just need space for the NUL. */
		if (__sferror(fp) || expandtofit(linep, 1, linecapp))
			goto error;
		FUNLOCKFILE(fp);
		(*linep)[0] = '\0';
		return (-1);
	}

	linelen = 0;
	while ((endp = memchr(fp->_p, delim, fp->_r)) == NULL) {
		if (sappend(linep, &linelen, linecapp, fp->_p, fp->_r))
			goto error;
		if (__srefill(fp)) {
			if (__sferror(fp))
				goto error;
			goto done;	/* hit EOF */
		}
	}
	endp++;	/* snarf the delimiter, too */
	if (sappend(linep, &linelen, linecapp, fp->_p, endp - fp->_p))
		goto error;
	fp->_r -= endp - fp->_p;
	fp->_p = endp;
done:
	/* Invariant: *linep has space for at least linelen+1 bytes. */
	(*linep)[linelen] = '\0';
	FUNLOCKFILE(fp);
	return (linelen);

error:
	fp->_flags |= __SERR;
	FUNLOCKFILE(fp);
	return (-1);
}
It seems that you are correct. Thanks for your notice. Here in Jordan you won't find C developers but you will find many .net(tm) developers.
 
achix said:
This is not the correct place to ask. Go to the appropriate mailing lists.

clang/llvm seems to perform better than the archaic gcc 4.2.1. FreeBSD/PC-BSD seem to lack behind debian/ubuntu in most benchmarks due to the old gcc. In fact it is a surprise that FreeBSD wins in some (few) benchmarks. So, you would help if you contacted the right people.

Do you believe Phoronix nonsense "benchmarks" have anything to do with reality? Compare some Debian with FreeBSD in a real environment, test it under load, see the difference. Apart from that, do you think GCC yields magic? *BSD is designed for quality and reliabilty. FreeBSD does things different under the hood, that's the major problem at least while running artificial benchmarks. See e.g. Povray, an old renderer once made for the Amiga (dkbtrace), then developed on DOS and later ported to Linux. If you want a state of the art renderer go with Yafray. The problem with Phoronix is, they don't really have a clue what they're doing. Remember: *BSD isn't a Linux distro, but a completely different operating system.
 
x(

I don't wanna be offensive but some time I feel that every body try to go out of topic of thread , that repeated every time x(
 
darkshadow said:
I don't wanna be offensive but some time I feel that every body try to go out of topic of thread , that repeated every time x(

I can agree to that. It tends to happen when the topic is considered solved, I think.

You asked for the production quality of clang, which is something I would give as "it is". Clang is used in the XCode environment of Apple, and you can say about them or their fans what you want but it is highly unlikely that they would get away with it if the thing would break much code.

There is, for me, only the question what "production ready" means for you. If it means to do each and everything exactly like gcc, then the answer is "no, it is not ready and will hopefully never be". If it means that it can build large software bases, then the answer is "yes". But if that software depends on specifics of gcc, then there is some work involved to clean that up, but that would not be the fault of clang but the fault of the author who considers only gcc (and linux).
 
aragon said:
Unfortunately clang will only replace GCC for the base. Many ports will still be reliant on GCC...

So will we have two compilers in base? Or will the ports trigger gcc as a dependency?
 
UNIXgod said:
So will we have two compilers in base? Or will the ports trigger gcc as a dependency?

I am just waiting for gcc then to have a dependency on another gcc. :\

How many ports explicitly depend on GCC? Note to self : participate in the "test ports with clang" group.
 
darkshadow said:
I don't wanna be offensive but some time I feel that every body try to go out of topic of thread , that repeated every time x(

If you want to hear something like Amen in the church, then the context operating systems is definitely the wrong matter to discuss. Just the question about the production quality of a compiler offers a plethora of possibilities to answer. It depends heavily on the point of view.
 
All I can conclude from this thread is that the original question was not clear enough. So try to post more precise questions so there are no general discussions due to lack of focus. Speaking for myself, I still don't understand what it is you want to know; something that Crivens (post #13) alluded to as well: what is "production-ready"? And as achix (post #2) said: this is a question that looks more at home on developers' mailing lists than on a user forum where the focus is less on 'compiler production and benchmarking'.
 
Crivens said:
How many ports explicitly depend on GCC? Note to self : participate in the "test ports with clang" group.

Yeah, I need to get busy and test the ports I maintain. Thanks for the nudge!
 
Eponasoft said:
I like CLang's license better than gcc's but I hate the GPL with all my heart so any license is better. :p

... had to read some EULA recently? *shudder* I'm glad our local law allows us to /dev/null such shrink-wrap legal fuzz.


@OP: I will summarize my position on the topic as (I want to be short here, not offensive):

The thread was disturbed by a false negative. You asked if clang is production ready, and a lot of the commenters here did say it is. The problem was you had a bug in your test code which let you to belive it is not. Such things happen. After fixing the code, you found it worked.

So, what would you want us to do?

The question you also asked is also if clang is ready for production in FreeBSD (since this is a FreeBSD forum, such things creep over). And that is a question which is debatted now.
 
darkshadow said:
...

It seems that you are correct. Thanks for your notice. Here in Jordan you won't find C developers but you will find many .net(tm) developers.

You did not need to read source of libc to figure this out. All you had to do is carefully read man page for getline(). Same goes for rest of the functions.
 
Back
Top