User talk:NicM

Archives: 1 2

Talk:OpenBSD
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)
 * 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).

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 views here, here, and here for examples. So please justify your change and your statement that this is nonsense. Thank you. Reinderientalk/contribs 15:11, 31 July 2008 (UTC)
 * 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).
 * 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/contribs 00:40, 4 August 2008 (UTC)
 * 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).
 * 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/contribs 15:39, 8 August 2008 (UTC)
 * Note that the fact that char *cp = i; does in fact create a conversion warning is typesafe behaviour. Reinderientalk/contribs 16:05, 8 August 2008 (UTC)
 * 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).
 * Also note that this whole discussion could be considered moot, as Wikipedia's opinion on C type safety is that the entire language is unsafe. That being said, I consider there to be degrees of type safety. I think it's best that we move this discussion to the Type safety talk page. Reinderientalk/contribs 16:28, 8 August 2008 (UTC)
 * WP is not a citable source ;-P. NicM (talk) 01:15, 9 August 2008 (UTC).

4.4
Well ya, you can beat all of us to it by posting the new version a few hours before it's even out yet. France Surrenders. 142.161.171.219 (talk) 09:55, 1 November 2008 (UTC) Some.Canadian.IP.Address


 * Hay, and their FTP server has not crashed yet, o' the power of UNIX. 142.161.171.219 (talk) 09:57, 1 November 2008 (UTC) Some.Canadian.IP.Address
 * Actually it was a few hours after it was released. Besides, I didn't know this was a competition? :-) NicM (talk) 17:13, 31 December 2008 (UTC).

OpenBSD
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)
 * 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)

ArbCom elections are now open!
MediaWiki message delivery (talk) 12:55, 23 November 2015 (UTC)

Proposed deletion of Conary (package manager)


The article Conary (package manager) has been proposed for deletion&#32;because of the following concern: "Not notable. There are no independent sources"

While all constructive contributions to Wikipedia are appreciated, pages may be deleted for any of several reasons.

You may prevent the proposed deletion by removing the notice, but please explain why in your edit summary or on the article's talk page.

Please consider improving the page to address the issues raised. Removing will stop the proposed deletion process, but other deletion processes exist. In particular, the speedy deletion process can result in deletion without discussion, and articles for deletion allows discussion to reach consensus for deletion.

''' This bot DID NOT nominate any of your contributions for deletion; please refer to the history of each individual page for details. ''' Thanks, FastilyBot (talk) 10:00, 21 March 2022 (UTC)