Per the Talk page guidelines regarding header templates, small should only be used for a very number of templates, as in two screen pages worth (like this, and then only minimally (as seen in in the current version of the same page). The OpenBSD does not have that large a set of templates, and the skip to TOC easily allows quick navigation to the talk menu. I moved the v5 banner into the project shell, as it can be fit in there, to save a little space, but really the thing that takes up the most space is the To-Do box. However, making it small also makes it very unwieldy and hard to read. The current number of boxes is minimal, and within the acceptable range for not using the small option, so please allow it to remain in this format. Collectonian (talk) 07:38, 13 April 2008 (UTC)[reply]
This was previously discussed and the outcome was that instead of removing some of the more egregiously useless boxes we decided that making them smaller was a good compromise - the information is still there if needed but it does not distract from the point of the talk page, which is to discuss the article. It doesn't matter if this stuff is hard to read, it is of fringe interest beside the page content. Two pages of boxes is IMO wildly excessive, I don't believe this is policy and a skip to TOC button does not make it okay.
However, I've now removed the todo as well (it had not been touched or any interest taken in it in a long time) and I am happy enough with the current approximately half a page taken up (at least since the last time good steps have been taken to reduce box size and to make common boxes combined/hideable). Although I do not think there is scope to add any more boxes, if someone wants the todo back or to add new boxes I think this will need to be revisited. NicM (talk) 18:43, 13 April 2008 (UTC).[reply]
malloc
Concerning your change and malloc's typesafeness, I repeat what I asked Dampam (he hasn't replied): Here is my rationale for saying that malloc is not typesafe. There is no compiler-enforced type check when calling malloc. With new, if one tries: char *foo = new float; An error is issued. However, if one tries char *foo = malloc(sizeof(float)); No error is issued. That's the definition of lack of type safety. Resources that I look up on the Internet echo my viewshere,here, andhere for examples.So please justify your change and your statement that this is nonsense. Thank you. Reinderientalk/contribs15:11, 31 July 2008 (UTC)[reply]
Addresses returned from malloc are of type void *, so char *foo = malloc(sizeof (float)); is fine, there is no type, it is no more type unsafe than char *s = "abc"; int *ptr = malloc(strlen(s)); or int *ptr = malloc(10);. NicM (talk) 20:58, 1 August 2008 (UTC).[reply]
This is the point: the compiler thinks it's "fine", but the problem is one of a disparity between programmer intent and compiler effect. Ideally the compiler should be able to warn the programmer whenever data of a certain type are being allocated and assigned to a pointer whose type does not match. malloc allows for no such mechanism. Reinderientalk/contribs00:40, 4 August 2008 (UTC)[reply]
No more than does eg int i; void *ptr = &i; char *cp = i;, the malloc function is not innately type unsafe any more than anything else in C which uses void * is type unsafe. When you do malloc(sizeof (int)) you are not allocating data of type int, you are allocating (usually) 4 bytes, referenced by a pointer of type void *. NicM (talk) 05:26, 5 August 2008 (UTC).[reply]
It can be easily shown that any usage of void pointers is type-unsafe, since void has no type at all. And as to the int example, it's true that you aren't allocating data of type int - you're allocating data that has _no type at all_. The difference between new and malloc is that new allocates data by the programmer specifying a type (and optionally an array length), whereas malloc has no use for type, only for byte length. The absence of any and all type information from malloc makes it type-unsafe. Reinderientalk/contribs15:39, 8 August 2008 (UTC)[reply]
I meant cp = ptr, which will not normally generate a warning; my opinion is that attempts to class this as type-unsafe are not terribly applicable: a void pointer does have a type (it is of type "pointer to object of unspecified type" in the same way "NULL" is "no pointer"), compilers will warn about conversions between other types (as you say about my *cp = i mistake), void is _explicitly_ untyped, so how can malloc be unsafe, since it returns void *? Sorry, I'm really pushed for time ATM so forgive me if I only reply occasionally. To get all my points in at once, malloc is a bit technical (mind you, type safety is a lot worse) and C-focused, a reformat and a lot more cites wouldn't go amiss. NicM (talk) 01:14, 9 August 2008 (UTC).[reply]
Hi NicM - I'm just stopping by to see if you are still interested in working on the OpenBSD article. A couple of editors have asked for more references in some areas, and the FARC is being held up from being closed due to these issues. If you feel that the fact tags are in error, you can always dispute them on the FARC page, or by specifically asking the editor who placed them on their talk page. I hope you are still interested in working on this article - it is always great to see articles improved and kept through the FAR process! Please let me know if you have any questions, Dana boomer (talk) 01:14, 11 May 2010 (UTC)[reply]
Hi again, Nic. Just another ping... There have been some image issues raised on the review page. At this point, these image concerns are pretty much the only thing holding up the article's review; once these are taken care of the review should be able to be closed as a keep, unless something else major comes up in the meantime. Thanks in advance, Dana boomer (talk) 16:09, 27 May 2010 (UTC)[reply]
You may prevent the proposed deletion by removing the {{proposed deletion/dated}} notice, but please explain why in your edit summary or on the article's talk page.