# is clang production-ready?



## darkshadow (Oct 25, 2010)

if you compile this code with gcc it will work with no proplem 

```
#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 

```
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


----------



## achix (Oct 26, 2010)

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.


----------



## Crivens (Oct 26, 2010)

darkshadow said:
			
		

> if you compile this code with gcc it will work with no proplem
> 
> ```
> n = getline(&line , &line_cap , fileToCompare[y]);
> ...


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.


----------



## expl (Oct 26, 2010)

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.


----------



## darkshadow (Oct 26, 2010)

*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


----------



## Crivens (Oct 26, 2010)

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.


----------



## phoenix (Oct 27, 2010)

Crivens said:
			
		

> Such things are called Heisenbug sometimes.



I believe you mean the Heisenburg Uncertainty Principle.  

Or, possibly, Murphy's Law.    (As in, just because it works now, doesn't mean it will work tomorrow.)


----------



## fronclynne (Oct 27, 2010)

http://www.jargon.net/jargonfile/h/heisenbug.html


----------



## darkshadow (Oct 27, 2010)

```
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.


----------



## wblock@ (Oct 27, 2010)

phoenix said:
			
		

> I believe you mean the Heisenburg Uncertainty Principle.



Isn't that the one where a vowel may be either a "u" or an "e" but can't be determined accurately because it's going too fast?


----------



## oliverh (Oct 27, 2010)

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.


----------



## darkshadow (Oct 28, 2010)

*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(


----------



## Crivens (Oct 28, 2010)

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).


----------



## UNIXgod (Oct 28, 2010)

I'm looking forward to clang replacing gcc in FreeBSD 9.x


----------



## aragon (Oct 28, 2010)

Unfortunately clang will only replace GCC for the base.  Many ports will still be reliant on GCC...


----------



## UNIXgod (Oct 28, 2010)

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?


----------



## Crivens (Oct 28, 2010)

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.


----------



## oliverh (Oct 28, 2010)

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.


----------



## darkshadow (Oct 28, 2010)

If you saw the egg and checked you will understand what I mean 
http://forums.freebsd.org/showthread.php?t=18761
I have no problem with any new topic my only problem that I don't get the answer while somebody trying to distort the community.


----------



## DutchDaemon (Oct 29, 2010)

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'.


----------



## ckester (Oct 29, 2010)

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 (Oct 29, 2010)

I like CLang's license better than gcc's but I hate the GPL with all my heart so any license is better.


----------



## Crivens (Oct 29, 2010)

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.



... 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.


----------



## expl (Oct 29, 2010)

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.


----------

