I prefer CURLOPT_WRITEDATA before CURLOPT_FILE

docs/libcurl/libcurl-tutorial.3

@@ -188,24 +188,27 @@ similar to this:
 You can control what data your function get in the forth argument by setting
 another property:
 
-    curl_easy_setopt(easyhandle, CURLOPT_FILE, &internal_struct);
+    curl_easy_setopt(easyhandle, CURLOPT_WRITEDATA, &internal_struct);
 
 Using that property, you can easily pass local data between your application
 and the function that gets invoked by libcurl. libcurl itself won't touch the
-data you pass with CURLOPT_FILE.
+data you pass with CURLOPT_WRITEDATA.
 
 libcurl offers its own default internal callback that'll take care of the data
 if you don't set the callback with CURLOPT_WRITEFUNCTION. It will then simply
 output the received data to stdout. You can have the default callback write
 the data to a different file handle by passing a 'FILE *' to a file opened for
-writing with the CURLOPT_FILE option.
+writing with the CURLOPT_WRITEDATA option.
 
 Now, we need to take a step back and have a deep breath. Here's one of those
 rare platform-dependent nitpicks. Did you spot it? On some platforms[2],
 libcurl won't be able to operate on files opened by the program. Thus, if you
-use the default callback and pass in a an open file with CURLOPT_FILE, it will
+use the default callback and pass in a an open file with CURLOPT_WRITEDATA, it
-crash. You should therefore avoid this to make your program run fine virtually
+will crash. You should therefore avoid this to make your program run fine
-everywhere.
+virtually everywhere.
+
+(CURLOPT_WRITEDATA was formerly known as CURLOPT_FILE. Both names still work
+and do the same thing).
 
 There are of course many more options you can set, and we'll get back to a few
 of them later. Let's instead continue to the actual transfer: